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GET ON THE “PAWS" EXPRESSWAY’ 



Why not take the shortest and fastest route 
toward system design solutions? To define 
and model a large, complex system, you 
need a modeling tool that can address the 
system's total architecture. 

PAWS/GPSM™ is an easy-to-use high 
0 $ productivity modeling and simulation 

tool that lets you evaluate alternative 
architectures while focusing on performance. 
It provides a state-of-the-art environment for 
developing accurate and reliable product 
definitions. 

00 PAWS provides high level primitives 
I % closely resembling the user's intuition. 

PAWS models the behavior of a total 
system implemented in diverse technologies 
including software, hardware, and firmware. 


00 GPSM, the graphical interface to 
PAWS, helps you quickly and easily 
transfer your ideas into pictures. GPSM 
helps you visualize multiple data and control 
flows through several components and 
incrementally synthesize models of a total 
system. 

0 0 PAWS/GPSM is flexible. It lets you refine 
0 # your model as your system design 

evolves so you can eliminate potential 
problems as early as possible in the product 
design cycle. 

Call (512) 474-4526 to receive information 
on PAWS/GPSM. And get on the PAW5 
expressway to system design solutions. 


IRA 


Information Research Associates • 911 W. 29th St. • Austin, Texas 78705 • ( 512 ) 474-4526 


























































SIMULATION BREAKTHROUGH 


BEFORE 



Difficult to understand results 


AFTER 



You see an animated picture of the 
system you are studying~any application 


Announcing new 

PC AT SIMSCRIPT II.5 with SIMANIMATION 
Your simulation results are now easy-to-understand 


W ith PC SIMSCRIPT II.5 
and the new simulation 
animation, your results are easy to 
understand—an animated picture, 
histograms, pie charts and plots. 

Because your results are under¬ 
stood, your recommendations are 
more likely to be acted upon. 

You can save your organization 
Lots of money and further your 
career. 

Simulation animation simplified 

SIMSCRIPT II.5 gives you a 
compact English-like language. 
Your simulation program reads like 
a description of the system you are 
studying. Animation is easy. 

Your model development, check¬ 
out, modification and enhancement 
are greatly simplified. 

Many successful applications 
SIMSCRIPT II.5® is a well 
established, standardized, and 
widely used language with proven 
software support. 

Typical applications include: 
military planning, manufacturing, 
communications, logistics, and 
transportation. 


Free trial and training 

The free trial contains every¬ 
thing you need to try PC SIM¬ 
SCRIPT II.5 on your computer. 

We send you PC SIMSCRIPT 
II.5, installation instructions, sam¬ 
ple models, and a complete set of 
documentation. 

You can build your model or 
modify one of ours. If you have 
questions, just call us for an im¬ 
mediate response. 

No cost, no obligation. 

Act now—limited offer 

For a limited time we also in¬ 
clude free training. Typical ap¬ 
plications are explained and 
demonstrated. 

Call today to avoid disappoint¬ 
ment. 

For immediate information 

Call Rick Crawford at (619) 
457-9681. In the UK, call Steve 
Wombell on (01) 940-3606. 

With PC SIMSCRIPT H.5 you 
get results sooner and they are 
better understood. 


Rush information on 

PC AT SIMSCRIPT II.5 with 

animation 

Free trial- learn the reasons for the 
broad and growing popularity of 
SIMSCRIPT II.5 — no cost, no obliga- 

Limited offer- return the coupon today 
and we will include one free course enroll¬ 
ment worth $950. 


Operating Systeir 


Return to: 

CACI IEEEC ™ 

3344 North Torrey Pines Court 
La Jolla, California 92037 

Or, better yet, call Rick Crawford at 
(619) 457-9681 
In the UK 

CACI 

26 The Quadrant 

Richmond, Surrey, England TW9 1DL 

Call Steve Wombell on (01) 940-3606 


SIMSCRIPT II.5, SIMANIMATION, and PC 
SIMSCRIPT II.S are registered trademarks and : 
marks of CACI, INC.-FEDERAL 
©1987 CACI, INC.-FEDERAL 
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Texas Instruments has 
system developers need. 
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“Personal Consultant™ Plus.. ♦ offers 
a very fine expert system development 
and delivery tool that already has 
a proven record with end-users.” 

— Susan Shepard, Al Expert 
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what serious expert 
Power tools. 




.Among all the expert system devel¬ 
opment tools available for personal 
computers today, none deliver the 
power and flexibility of TI’s Personal 
Consultant series. 

Personal Consultant Easy is ideal for 
getting started, and is upwardly com¬ 
patible with the higher functionality of 
PC Plus. For experienced developers, 
Personal Consultant Plus and its 
optional add-on enhancements, Online 
and Images, were designed to help solve 
a broader range of complex problems. 


package helps deliver expertise that is 
“online all the time.” 

Application delivery as flexible as the 
tools themselves. 

Delivery can be in LISP for flexibility, 
or “C”* for maximum speed and porta¬ 
bility. Our “C” options support either 
stand-alone or “embedded” knowledge 
bases. Options are available for DOS- 
based^PCs, TPs Explorer, and DEC’s 
VAX™ line of multi-user minis running 
under VMS™. 



Personal Consultant Plus. Full power 
for an affordable price. 

At $2,950, PC Plus has proven to be 
one of the richest and most flexible 
problem-solving tools available for the 
development of complex knowledge- 
based systems. Designed to take 
advantage of today’s more powerful 
286/386 DOS-based computers, or TPs 
Explorer™ Symbolic Processing System, 
the new 3.0 version of PC Plus provides 
powerful standard features and a contin¬ 
uing growth path with the addition of 
either PC Images or PC Online, or both. 

Personal Consultant Images. Picture 
an expert system with interactive 
graphics. 

At $495, PC Images enables developers 
to create knowledge-based applications 
that incorporate complex graphical 
“active images.” User-interactive dials, 
gauges, forms and selection images pro¬ 
vide a more exciting visual data input 
and output style. 

Personal Consultant Online. The 
expert system as part of the process. 

At $995, PC Online allows the devel¬ 
oper to design expert systems which 
interact directly with process data, as 
opposed to input from a human oper¬ 
ator. Designed for intelligent process 
monitoring applications, this optional 


“Texas Instruments has done more 
than any other company to educate 
people about AI, to popularize it, and 
to make useful AI tools available at 
reasonable prices. ” 

—Jim Seymour, PC Magazine. 

Technical support, training courses and 
Knowledge Engineering Services are 
available for the Personal Consultant 
products. If you have a question about 
any of our expert system power tools, we 
have the answer. 


Pick up the phone and gain a powerful 
advantage. 

Call 1-800-527-3500 for technical 
overviews of our products and a PC Plus 
case histories brochure which details 
how our power tools are being put to 
work today. 
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President’s MESSAGE 



Roy Russo 


O ne of the most meaningful 

things that can happen in your 
career is to be recognized by 
your peers for your accomplishments. 
In this month’s column, Ralph Preiss, 
chair of the Computer Society Awards 
Committee, and Tilak Agerwala, chair 
of the Computer Society Fellows Com¬ 
mittee, discuss the ways in which the 
Computer Society and the IEEE recog¬ 
nize technical and service contributions 
in the computer field. 


Roy Russo 
President 


Recognition by peers 

One of the Computer Society’s stand¬ 
ing committees is the Awards Commit¬ 
tee. Its function is to oversee the extensive 
program for recognition of contributors 
to computer science and technology by 
professional peers and to modify the 
program in light of changing needs. The 
Computer Society awards program fits 
within the framework established by the 
IEEE, and complements IEEE awards 
in disciplines of interest to the society’s 
membership. Two categories of recogni¬ 
tion are defined, the technical and the 
service awards. 

Technical awards. The Computer 
Society’s highest technical award is the 
W. Wallace McDowell award. It is also 
the society’s oldest award, having been 
presented yearly since 1966. Its recipients 
are chosen for outstanding recent con¬ 
tributions to theory, design, education, 
or practical applications falling within 
the society’s scope of interest. The list 
of McDowell Award recipients — from 
the earliest to the most recent — represents 
the best of who’s who in international 
computer innovations. For example, 
early winners include Fernando Cor- 
bato of MIT, who made time-sharing of 
large-scale computers possible; Sey¬ 
mour Cray, then with Control Data 
Corporation, for his large-scale scien¬ 
tific computers; Frederick Brooks, the 
father of IBM’s System/360 Operating 
System; and Tom Kilburn, University 
of Manchester, for powerful computers 
employing paging. Among the more 
recent recipients are the late Daniel 
Slotnick, University of Illinois, for 
centrally controlled parallel computers; 
Thomas McWilliams and Lawrence 
Widdoes, Jr., for developing the struc¬ 
tured computer-aided logic design 
methodology at Stanford University; 
and William Strecker, the principal 
designer of the Digital Equipment Cor¬ 
poration’s VAX architecture, 

The Eckert-Mauchly Award is 
awarded jointly by the ACM and the 


Computer Society for outstanding con¬ 
tributions to the field of computer 
architecture. John Cocke received this 
award in 1986 for his work on RISC 
machines, and Gene Amdahl received it 
in 1987 for his contributions to large- 
scale computer architecture. 

Technical Achievement Awards are 
given for outstanding and innovative 
contributions in the fields of computer 
science or computer technology, usually 
within the past 10 and not more than 15 
years. Among the recipients are Algirdas 
Avizienis of UCLA for his contribu¬ 
tions to fault-tolerant computing and 
Edward McCluskey of Stanford Univer¬ 
sity for his contributions to digital test¬ 
ing techniques. 

In addition, the society’s Board of 
Governors has established two other 
prestigious awards: the Computer 
Pioneer Award, given since 1982 for 
pioneering contributions to the com¬ 
puter field, and the Computer 
Entrepreneur Award, given since 1986 
for managerial accomplishments result¬ 
ing in the growth of the computer 
industry. The 1987 Computer Pioneers 
are Rey Johnson, now retired from 
IBM, for the IBM RAMAC, the first 
computer based entirely on disk drives 
for large memory; Robert Everett, now 
retired from Mitre, for his contribu- ; 

tions to the Whirlwind I computer; 

Arthur Samuel, with IBM at that time 
but now at Stanford University, for his 
early work on adaptive logic systems; 
and Peter Wirth from ETH, the Swiss 
Institute of Technology, for the widely 
used computer language Pascal. The 
1987 Computer Entrepreneurs are Gor¬ 
don Moore and Robert Noyes, both 
from Intel. 

Service awards. The society recog¬ 
nizes its volunteers and staff with cer¬ 
tificates for their contributions in 
planning and conducting such activities 
as standards development, conferences. 
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workshops, and other technical meet¬ 
ings, publications, and support of chap¬ 
ters activities, as well as for the more 
administrative functions such as office 
operations, budgeting, and planning. 

The highest service award for volun¬ 
teers is the Richard E. Merwin Distin¬ 
guished Service Award. The most recent 
recipient is Ted Bonn, who has been 
active in the society and its predecessor 
organizations since 1951. Though 
retired from Honeywell Information 
Systems, Ted has continued his active 
role in the Boston area and conducted 
the very successful Boston Tutorial 
Week. 

The highest staff award is the Harry 
Hayman Award for Distinguished Staff 
Service, which will be presented for the 
first time at the 1987 Fall Joint Com¬ 
puter Conference to H. True Seaborn, 
editor and publisher of the Computer 
Society. True has been a leading par¬ 
ticipant in the meteoric growth of the 
Computer Society from 16,000 mem¬ 
bers in 1973 to over 90,000 this year. 

The other certificates, in rank order, 
are the Distinguished Service, Outstand¬ 
ing Contribution, and Meritorious Ser¬ 
vice Awards and the Certificate of 
Appreciation. 

The Distinguished Service Award is 
given for long and distinguished service 
to the society at a level of dedication 
and achievement rarely demonstrated; it 
often includes service in several capaci¬ 
ties and positions of significant respon¬ 
sibility, with contribution levels 
justifying multiple Meritorious Service 
Awards or higher. 

The Outstanding Contribution 
Award represents an achievement of 
major value and significance to the 
Computer Society. The achievement 
should be a specific, concisely charac¬ 
terized accomplishment, as opposed to 
a collection of different efforts. 

The Meritorious Service Award is for 
meritorious and significant service to 



Ralph Preiss, Awards Committee Tilak Agerwala, CS Fellows Committee 


Fellow nominations 

The Computer Society Fellows Committee urges members to take on the 
task of identifying worthy candidates, completing the necessary paperwork, 
and meeting the deadline for submission of the fellows nomination to the 
IEEE. Nominators should start the process now since it takes a fair amount of 
preparation to make a strong case and identify appropriate references. Nomi¬ 
nation kits may be obtained either from IEEE Headquarters, Fellow Commit¬ 
tee, IEEE, 345 East 47th Street, New York, NY 10017-2394, or from the 
Computer Society of the IEEE, Member Services, 10662 Los Vaqueros Circle, 
Los Alamitos, CA 90720-2578. A strict deadline of April 30,1988, is imposed to 
have all the nomination forms (B-27, B-3, and B-29) back to the IEEE. 

In evaluating nominations, the IEEE Fellows Committee considers the fol¬ 
lowing criteria, listed in approximate order of importance: 

(1) individual contributions as engineer/scientist/originator, technical 
leader, or educator; 

(2) evaluation by an IEEE society; 

(3) tangible and verifiable evidence of technical accomplishment such as 
technical publications, patents, reports, or published descriptions of 
products, facilities and/or services performed; 

(4) confidential opinions of IEEE fellows who are qualified to judge the work 
of the candidates (where possible, these should be associated with other 
than the candidate’s own organization); 

(5) Service to IEEE (AIEE/IRE) and other professional engineering societies; 
and 

(6) total years in the profession. 

Tilak Agerwala, CS Fellows Committee Chair 

IBM Corporation, Old Orchard Rd., Armonk, NY 10504 

(914) 765-6491 
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any Computer Society-sponsored 
activity. Qualification is enhanced by 
the level and number of contributions, 
excellence, dedication, and tenure in 
service. 

The Certificate of Appreciation 
recognizes creditable service to any 
Computer Society-sponsored activity. 

IEEE membership grades. The elec¬ 
tion to IEEE fellow grade is a distinct 


honor conferred to an individual as a 
recognition of outstanding contribu¬ 
tions to the profession. It is the highest 
grade of membership and is the only 
grade for which members cannot apply, 
but must be nominated by another 
member. Only senior members with at 
least five years of membership in that 
grade are eligible to be nominated. 
Thirty-five senior members of the Com¬ 
puter Society were elected to fellow 


grade for 1987; clearly, we have many 
more members who deserve this recog¬ 
nition. 

Members are urged to apply for 
senior membership since this is one 
requirement for elevation to the grade 
of fellow. Admission or transfer to sen¬ 
ior membership requires that the candi¬ 
date be an engineer, scientist, educator, 
technical executive, or originator in 
IEEE-designated fields and have been 


Examples of IEEE technical and prize paper awards 

The Awards Committee has two subcommittees — the IEEE Awards Search 
Committee and the External Awards Search Committee — that help nomina¬ 
tors expedite their nominations. If necessary, these committees act as refer¬ 
ences for nominations of Computer Society members for other professional 
awards, such as the AFIPS Harry Goode Award and the ACM Turing Award, 
and for IEEE awards, such as those listed below. 

Emmanuel R. Piore Award. For outstanding achievement in the field of 
information processing; in relation to computer science, for contributing sig¬ 
nificantly to the advancement of science and to the betterment of society. 
Nominations and support material must be at IEEE Awards Board by April 1 
for consideration that year. 

Charles Proteus Steinmetz Award. For major contributions to the develop¬ 
ment of standards in the field of electrical and electronics engineering. Nomi¬ 
nations and support material must be at IEEE Awards Board by April 1 for 
consideration that year. 

Koji Kobayashi Computers and Communications Award. For recent out¬ 
standing technical contributions in the field of computers and communica¬ 
tions, i.e., integration of computers and communications. Nominations and 
support material must be at IEEE Awards Board by April 1 for consideration 
that year. 

W.R.G. Baker Prize Paper Award. Outstanding paper describing original 
work in an IEEE periodical; awarded for a paper published in the January 1 to 
December 31 time period immediately preceding the nomination date. Nomi¬ 
nations and support material must be received by the IEEE Awards Board by 
July 1 for consideration that year. 


Awards Committee 

The Computer Society Awards 
Committee has subcommittees that 
solicit and act on nominations from 
the membership. To obtain additional 
information, nomination forms, or a 
full list of awards, please contact the 
appropriate chair or use number 198 
on the Reader Service Card. 
(Compmail+ subscribers have 
access to an on-line nomination form 
by entering “request awards" instead 
of “mail” after the “>” prompt.) 


Awards Chair: 

Ralph Preiss, (914) 435-8185 

Awards Policy: 

Ned Kornfield, (215) 499-4055 

Eckert-Mauchly: 

John Riganati, (301) 731-3741 

W. Wallace McDowell: 

Rex Rice, (415) 854-5205 

Technical Achievement and Com¬ 
puter Entrepreneur: 

Arthur Pohm, (515) 294-8396 


Donald G. Fink Prize Paper Award. Outstanding survey, review, or tutorial 
paper in an IEEE periodical; awarded for a paper published in the January 1 to 
December 31 time period immediately preceding the nomination date. Nomi¬ 
nations and support material must be received by the IEEE Awards Board by 
July 1 for consideration that year. 


Computer Pioneer: 

Harry Huskey, (408) 423-4050 

External Awards Search: 

Claud Davis, (914) 742-5929 


Browder J. Thompson Prize Paper Award. Outstanding paper by an author 
under 30 years of age at the time of submission of the first manuscript to an 
IEEE periodical; awarded for a paper published in the January 1 to December 
31 time period immediately preceding the nomination date. Nominations and 
support material must be received by the IEEE Awards Board by July 1 for 
consideration that year. 

Nomination kits for these awards may be obtained from IEEE Headquarters, 
IEEE Awards Board, 345 East 47th Street, New York, NY 10017-2394. 


IEEE Awards Search: 

Marshall Yovits,(317) 274-0634 

Society Search: 

Tse-yun Feng, (814) 863-1469 

Richard E. Merwin Distinguished 
Service: 

Samuel Horvitz, (203) 440-4877 
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active in professional practice for at 
least 10 years, with significant perfor¬ 
mance over a period of at least five of 
these years. (Senior member applica¬ 
tions are available from the Computer 
Society by using number 204 on the 
Reader Service Card.) 

Best paper awards. Best papers in 
society publications are identified by 
editors and editorial board members 
and are nominated for IEEE awards, 
such as the Baker for original work, the 
Thompson for a writer under 30 years 
of age, and the Fink awards for the out¬ 
standing survey, review, or tutorial 
paper. 

Several Computer Society confer¬ 
ences grant awards for the best paper 
and the best presentation. The judging 
is performed either by a volunteer com¬ 
mittee of experts in the field or by the 
audience. Among these are the 
ACM/IEEE Design Automation Con¬ 
ference and the International Test Con¬ 
ference best paper awards, Medcomp’s 
selection of the Martin M. Epstein 


Memorial Best Paper, the Software 
Engineering Best Paper, and the K.S. 

Fu Memorial Best Paper in Pattern 
Recognition. 

The Lance Stafford Larson Memorial 
Award is presented annually to the best 
paper on a computer subject submitted 
to the annual IEEE Student Paper 
Competition. The $500 award is 
administered by a subcommittee of the 
Area Activities Board. 

Student awards. The society selects 
several students annually to receive 
$3000 each from the Richard E. Merwin 
scholarship fund at both the under¬ 
graduate and graduate levels. The Com¬ 
puter Society Design Automation 
Technical Committee awards fellow¬ 
ships to graduate students studying in 
the design automation field. They are 
announced at the annual ACM/IEEE 
Design Automation Conference, which 
also funds them up to $4000. The Test 
Technology Committee awards fellow¬ 
ships to students in the area of test tech¬ 
nology from funds supplied by the 


annual International Test Conference. 

The Computer Society, under its 
Area Activities Board, participates in 
the judging of high school science fairs. 
It also awards prizes in the area of com¬ 
puter science and engineering in the 
annual final judging at the International 
Science and Engineering Fair. The first 
prize is $250, the second $100, and the 
third is $75. 

We invite all members to participate 
in the Computer Society’s awards pro¬ 
gram. Opportunities for participating 
—and thereby serving your society and 
profession — range from judging a high 
school science fair to nominating and 
writing support letters for technical and 
service awards. 


Ralph Preiss 

Awards Committee Chair 
IBM Corporation 
F65/705-2 
PO Box 950 

Poughkeepsie, NY 12602 
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The IEEE Trial-Use Standard: a specific case 


To the editor: 

In reference to the discussions of 
IEEE Trial-Use Standards in the Sep¬ 
tember 1987 issue of Computer, it may 
help to provide some applicable data 
from the specific case of IEEE Standard 
730, IEEE Standard for Software Qual¬ 
ity Assurance Plans. 

During the initial formulation of 730, 
many steps were taken to publicize this 
effort, including presentations at the 
ACM Software Quality Assurance Con¬ 
ference, Fall Joint Computer Confer¬ 
ence, etc.; briefings of various industry 
and professional groups including ANS 
Zl; and the publication of a draft of the 
standard in Computer. Although tech¬ 
nical comments were solicited, none 
were received as a result of any of the 
above procedures. 

When the standard was initially 
presented to the 104 members of the 
balloting group for sponsor approval, 
the results were as follows—returns: 82 


(78.8 percent); approvals: 64 (88.9 per¬ 
cent); disapprovals: 8 (11.1 percent); 
and abstentions: 10. Based on these 
statistics, the standard was approved as 
a trial-use standard in 1979. 

After it was published as a trial-use 
standard, significant comments were 
received from, among others, the 
Nuclear Power Engineering Committee 
of the Power Engineering Society. 
Resolutions of these comments were 
implemented in the full-use standard 
(approved in 1981 with 100 percent 
approval). Further resolutions resulted 
in the approval of another revision in 
1984. 

This experience is instructive since 
publication of the draft did not result in 
any significant comments, perhaps due 
to the prior exposure of readers to the 
work at that time. However, approval 
and publication of the trial-use standard 
brought the effort.to the attention of 


affected interests outside of the infor¬ 
mation technology group. In this 
instance, the trial-use mechanism ful¬ 
filled its intended purpose. 

Fletcher J. Buckley 
Cherry Hill, N.J. 


Computer welcomes your letters. 

Send technical correspondence to Bruce 
D. Shriver, Editor-in-Chief, IBM T.J. 
Watson Research Center, PO Box 704, 
H0-B04A, Yorktown Heights, NY 10598. 
Send other comments to Letters Editor, 
Computer , 10662 Los Vaqueros Circle, 
Los Alamitos, CA 90720. 

All submissions are subject to editing 
for style, length, and clarity. 
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Integrated coverage of integrated environments 



Bruce D. Shriver 


This month both Computer and 
IEEE Software are publishing articles 
that cover a broad range of topics 
related to integrated design and pro¬ 
gramming environments. The maga¬ 
zines complement each other in their 
coverage of this increasingly important 
area. 

The articles appearing in Computer 
are surveys, tutorials, and case studies. 
They are intended to introduce Com¬ 
puter’s, general readership to the techni¬ 
cal issues associated with the design, 
implementation, and use of these envi¬ 
ronments. The articles provide a range 
of technical perspectives that should 
encourage more widespread use of inte¬ 
grated design and programming envi¬ 
ronments and spawn related new 
product, development, and research 
projects. 

The articles appearing in IEEE Soft¬ 
ware deal with more detailed technical 
issues and should give readers insight 
into the breadth and depth of current 
key issues in the environments area. 

The fact that Computer and IEEE 
Software are complementing one 
another this month did not happen by 
accident. This experiment has been 


quite some time in the making. Even 
before becoming editor-in-chief of 
Computer, I wanted to establish a 
mechanism whereby Computer and the 
Computer Society’s specialty magazines 
— IEEE Software, IEEE CG&A, 

IEEE Expert, IEEE Micro, and IEEE 
D&T — could work together to provide 
our readers with significant and in- 
depth coverage of important and timely 
topics. “Companion issues” are one . 
way of collaborating. This approach 
will also be attempted with multiple spe¬ 
cialty magazines. For example, Com¬ 
puter, IEEE Software, and IEEE 
Expert will be involved in companion 
issues on the use of AI technology in 
software engineering: Computer will 
publish a tutorial and survey article, 
IEEE Software will publish in-depth 
articles on the software issues, and 
IEEE Expert will publish articles deal¬ 
ing with the hard-core AI topics of such 
applications. 

This first attempt at this publication 
format involved a significant amount of 
time and interaction among Guest Edi¬ 
tors David Notkin and Peter Hender¬ 
son, myself, numerous authors, a very 
large body of referees, and the various 


parties’ assistants. We had a large num¬ 
ber of manuscripts submitted as candi¬ 
date articles for these companion issues, 
and we thank the authors of those 
papers for submitting them. David and 
Peter have given much time to making 
this an outstanding issue of both Com¬ 
puter and IEEE Software. Without 
their competence, diligence, and hard 
work, these issues would not have come 
to pass. 

The starting point for reading the 
articles is with David and Peter’s intro¬ 
duction. They provide a nice classifica¬ 
tion of problem areas within the field to 
guide the reader in characterizing the 
results the various authors report. 

If you do not subscribe to IEEE Soft¬ 
ware, we are making it extremely con¬ 
venient for you to obtain a copy. The 
table of contents for IEEE Software is 
given within the guest editors’ introduc¬ 
tion, and there are two postcards for 
ordering a copy — one in the middle of 
the magazine and one with our regular 
Reader Service Card at the back of the 
magazine. 

Bruce D. Shriver 

Editor-in-Chief, Computer 
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GUEST EDITORS’ INTRODUCTION 
Computer and IEEE Software Companion Issues 


Integrated Design and 
Programming Environments 

Peter B. Henderson, SUNY at Stony Brook 
David Notkin, University of Washington 



T here are several basic approaches 
to improving our ability to 
develop cost-effective high- 
quality software. 

• Powerful language mechanisms 
improve programmer productivity. For 
instance, high-level languages such as 
Ada, as opposed to assembly languages, 
give programmers increased leverage in 
building large systems. Similarly, one-in 
one-out control constructs generally help 
reduce the errors that programmers make, 
thereby decreasing debugging costs. 

• Programming paradigms — models 
of how programming should be done — 
help guide programmers in designing and 
structuring software systems. Paradigms 
define styles of thinking and programming 
that decrease the distance between the 
problem the programmer is solving and 
the program he or she produces. Different 
programming domains often demand 
different paradigms; for instance, a con¬ 
current programming paradigm eases the 
development of operating systems. Func¬ 
tional and object-oriented programming 
are other examples of powerful 
paradigms. 

• Careful definitions of software devel¬ 
opment processes help improve the result¬ 
ing software product. The earliest attempt 
at such a definition — the waterfall model, 
where requirement definition, specifica¬ 
tion, implementation, testing, and main¬ 
tenance were performed serially, with little 
feedback between phases — was not a 
realistic model of this process (although it 


was extremely useful in defining the notion 
of a software development process). More 
recent models — like rapid prototyping 1 
and Boehm’s spiral model 2 — are show¬ 
ing increased utility. 

• Reuse of existing software, avoiding 
original development to the greatest degree 
possible, is a well-recognized way to 
reduce software development costs. 
Mechanisms for finding and then sharing 
design and code are the current focus of 
numerous research efforts. 

Using the computer itself to aid soft¬ 
ware developers is the approach that we 
focus on in these companion issues of 
Computer and IEEE Software. Properly 
conceived and constructed software devel¬ 


opment environments increase both our 
productivity and the quality of the soft¬ 
ware we produce. 


Motivation 

Computer scientists have created 
numerous development tools for other dis¬ 
ciplines, such as computer-aided design 
and computer-aided manufacturing. Only 
relatively recently, however, has the need 
for computer scientists to aid themselves 
been recognized. Using computers to sup¬ 
port software development makes sense 
for three fundamental reasons. 
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Contents: 

IEEE Software companion issue 

Integrated Project Support with IStar by Mark Dowson 
Most integrated environments are built bottom-up, starting with language 
tools. But this limits comprehensive project support. IST’s system focuses on 
the overall project task instead. 

Parallel Software Configuration Management in a Network Environment by 

David B. Leblang and Robert P. Chase, Jr. 

DSEE provides the best of networks and parallelism. It lets resources be 
shared flexibly, and can reduce system build time from overnight to over 
lunch. 

Working in the Garden Environment for Conceptual Programming by Steven P. 
Reiss 

Program developers use a variety of techniques when creating their sys¬ 
tems. This automated design system conforms to the programmer. 

The Symbolics Genera Programming Environment by Janet H. Walker, David 
A. Moon, Daniel L. Weinreb, and Mike McMahon 
This Lisp-based system helps designers get from prototype to product 
faster. The key is an open architecture and highly integrated development 
tools. 

Multiuser, Distributed Language-Based Environments by Gail E. Kaiser, 

Simon M. Kaplan, and Josephine Micallef 

How do you keep teams of programmers informed of system changes with¬ 
out burying them in mail messages? Make the environment responsible for 
propagating changes. 

RPDE 3 : A Framework for Integrating Tool Fragments by William Harrison 
Monolithic tools that can’t be extended to handle new kinds of input, not 
just new function, are hampering development. This model seeks to change 
that. 

Distributed Management of a Software Database by Mark A. Linton 
The Allegro model demonstrates that communication among objects in 
different spaces can be implemented efficiently in a software-development 
database. 

To get your copy, use the postcard on page 144A. 


First, a great deal of the effort in con¬ 
structing software consists of menial tasks 
that can be automated — for instance, 
ensuring that object code has been com¬ 
piled using the desired switches. Using the 
computer for such tasks allows the user to 
concentrate on the more challenging tasks, 
like system and algorithm design, that 
arise in software development. 

Second, one of the most frustrating 
problems in software development is the 
difficulty of keeping code consistent with 
project information such as requirements 
and design documents, structure charts, 
and testing strategies. Using a computer 
permits much project information, which 
has historically been kept off line, to be 
kept on line, permitting environments to 
support the automatic and semi-automatic 
management of project information and 
code and the relationship between them. 
This information, once on line, is readily 
available to managers and other project 
personnel to help in coordinating project 
activities. 

Third, the availability of powerful 
workstations with sophisticated input and 
output capabilities now makes it cost- 
effective to give each individual program¬ 
mer the potential for interactive response 
times and rich user interfaces. These work¬ 
stations make possible the construction of 
tools, such as dataflow diagram editors, 
that were simply not feasible in the main¬ 
frame world. 

These three reasons arise, respectively, 
because of the ability of computers to 
compute tirelessly, to manage massive 
amounts of data, and to provide rich inter¬ 
action with users. 


Topics 

Research and development topics 
related to environments can be viewed 
along three dimensions — activity, 
domain, and mechanism. The activity 
dimension defines the range of software 
development and maintenance activities 
that an environment addresses. The 
domain dimension defines the class of 
software that the environment is intended 
to support. The mechanism dimension 
defines the mechanisms that characterize 
the environment’s internal and external 
organization. 

Activity dimension. Software develop¬ 
ment and maintenance includes a wide 
range of activities — for example, schedul¬ 
ing, requirements definition, specifica¬ 


tion, design, implementation, testing, cor¬ 
rection, retargeting, and enhancement. 
Environments can contribute to improved 
quality and productivity for any of these 
activities. Some environments focus on 
supporting a specific activity, while others 
focus on supporting a broad range of 
activities. 

To date, the most successful environ¬ 
ments have been those that focus on a nar¬ 
row and related set of activities. For 
instance, DSEE’s configuration manager 3 
facilitates the system composition and sys¬ 
tem generation activities. The more ambi¬ 
tious environments look to support the full 
range of software engineering activities. 
These broadly aimed environments appear 


to have the most promise for reducing the 
costs of software development, since they 
can help manage information that appears 
in many activities. Consider, for example, 
one scenario concerning activities that 
arises when a bug is reported from the 
field. Once the solution is found, the code 
must be changed, tested as a unit, and then 
run against a carefully defined set of 
regression tests. Then the change must be 
propagated, perhaps through the design 
specifications and documentation and cer¬ 
tainly through other versions of the sys¬ 
tem. An environment focused on 
debugging, for instance, cannot hope to 
help with most of these chores. This limi¬ 
tation of narrowly focused environments 
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leads us to pursue more broadly targeted 
environments. Despite the promise of 
these broader environments, however, no 
single instance has yet demonstrated, at 
least in any commercially clear-cut way, 
the ability to manage information success¬ 
fully across most activities. 

Domain dimension. Just as it is no 
longer generally accepted that there is a 
single programming language that is suita¬ 
ble for all tasks, it is not possible to con¬ 
struct a single environment that is suitable 
for all domains. Appropriate design tech¬ 
niques and debugging support, among 
others, must often vary from domain to 
domain; for example, a debugger for a 
functional language may not need to show 
“current” values of variables, since their 
state cannot change. Additional knowl¬ 
edge about a domain can always be used 
to improve the support an environment 
gives to its users. 

The original (and still a common) 
approach to constructing environments 
for different domains is to handcraft each 
one. The benefit of this approach is that 
embedding domain-specific knowledge is 
straightforward. Good examples of suc¬ 
cessful handcrafted environments include 
Cedar, 4 Xerox PARC’s single-language 
environment for building distributed sys¬ 
tems, and the Cornell Program Syn¬ 
thesizer, 5 a syntax-directed editing 
environment for introductory program¬ 
ming courses. The problem with hand¬ 
crafting environments is the development 
expense. Constructing environments is 
costly, closer to the costs of operating sys¬ 
tem development than to compiler devel¬ 
opment. 

But even diverse environments share 
many characteristics, often permitting 
reuse of abstractions and implementa¬ 
tions. Environments for Prolog programs 
and environments for parallel programs, 
for instance, might well share windowing 
systems and text editing capabilities. Simi¬ 
larly, environments for large-size C pro¬ 
grams and environments for Jackson 
System Design might share compilers, 
linkers, and documentation templates. 

Environment generation projects ease 
the construction of a family of environ¬ 
ments. The key to this approach is the 
explicit separation of an environment- 
independent kernel, which is shared across 
all environments in the family, from a set 
of environment-dependent definitions, 
which specialize the kernel for particular 
domains. In Gandalf, 6 one of the first 
environment generation efforts, the kernel 


defines a model of structure-oriented edit¬ 
ing (where users edit in terms of structural 
constructs, such as if-then-else statements 
and headers of mail messages), while the 
environment-specific information defines 
the actual structures of the environment, 
along with the semantics of these struc¬ 
tures. Environment generation efforts like 
Arcadia 7 broaden the environment- 
independent kernel to include an interpre¬ 
tation engine for environment-specific 
“process programs,” which explicitly 
define the software process model desired 
for a particular domain. 

The trade-off between the cost of 
developing environments and the support 
the environments provide to the user is not 
yet settled. The need for individual groups, 
or even individual users, to customize envi¬ 
ronments to their specific needs is evident. 
In some areas, like language syntax and 
semantics, suitable sharing is possible. The 
degree to which sharing and reuse is feasi¬ 
ble for other aspects of environments is 
cloudier. 

Mechanism dimension. Carefully 
designed and chosen mechanisms facilitate 
the development of an environment for a 
given domain and set of activities. To 
implement an environment, given a basic 
understanding of the requirements, the 
implementor must consider appropriate 
external and internal structures. 

External structures designate the style of 
interaction between the environment and 
its users; for instance, if the domain of the 
environment is novice programmers, a 
reliable and extremely flexible help facil¬ 
ity might be needed. Internal structures 
reflect on the way in which the environ¬ 
ment is composed; for instance, Unix tools 
are generally built around the notion of 
standard input/output, which helps com¬ 
pose tools in a batch-like fashion, but not 
in the interactive style needed by many 
environments. 

In many cases, only a fine line is drawn 
between mechanisms that support internal 
and external structuring. Consider the 
Pecan system, 8 for instance. A key notion 
of Pecan is that users should be allowed to 
see their program in several fundamentally 
different ways. For instance, a user might 
see a program either as lines of text or else 
as a Nassi-Shneiderman chart. This 
notion, however, places significant 
demands on the internal mechanisms, 
which must support techniques for defin¬ 
ing alternate views of viewing a program 
as well as techniques for keeping the views 
consistent (both visually and internally). 


There are three key things to note about 
environment mechanisms. First, there is 
an extremely close relationship between 
internal and external mechanisms; in 
general, internal mechanisms are devel¬ 
oped in response to external mechanisms 
and needs. Second, as has been demon¬ 
strated in operating systems, it is benefi¬ 
cial to separate mechanism from policy; 
that is, a mechanism should give the max¬ 
imum freedom possible to the implemen¬ 
tor that uses the mechanism. Third, to 
reduce the long-term costs of developing 
environments, it is necessary to develop 
mechanisms that are as ubiquitous as pos¬ 
sible, for use in environments of the same 
family as well as, perhaps, in others. 


Current status 

Research and development on environ¬ 
ments have achieved some successes and 
must be noted for some failures. 

Activities. Environments that focus on 
a relatively narrow range of software 
development activities have been success¬ 
fully constructed and used. Most notable 
are environments (like Smalltalk-80 and 
Interlisp) that concentrate primarily on the 
programming-in-the-small activities of 
editing, translating, executing, and debug¬ 
ging. Environments that support early 
activities in the software life cycle — such 
as IDE’s Software through Pictures 9 — 
are appearing now as well. Reasonably 
successful environments have been 
produced to support virtually every soft¬ 
ware development activity. 

However, it has not yet been demon¬ 
strated that the full range of activities can 
in fact be supported effectively within a 
single integrated environment. Efforts in 
this dimension — such as Gandalf, which 
supports programming-in-the-many (the 
cooperation, communication, and coordi¬ 
nation of multiple programmers), 
programming-in-the-large (the composi¬ 
tion of modules into systems), and 
programming-in-the-small — have 
produced prototypes rather than produc¬ 
tion systems. Although these prototypes 
show promise, full working environments 
are needed to substantiate the claims made 
for broad-based environments. 

Domains. Environments for some 
domains have also been successfully built 
and used. Cedar’s intention to support 
exploratory distributed-systems program¬ 
ming has largely been met, for example. 
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We cannot yet develop environments for 
widely varying domains in a cost-effective 
way. However, we are making strides in 
this direction due to our initial experiences 
with separating environment-dependent 
aspects from environment-independent 
aspects. We are broadening the domains 
we can accommodate by carefully, and 
usually formally, characterizing various 
aspects of software development. Exam¬ 
ples of such characterizations include 
abstract syntax trees, which drive 
structure-oriented editing environments, 
and program dependence graphs, which 
support debuggers and optimizers. As we 
increase our ability to deal with an 
expanded range of domains, we will be 
driven to consider environments that 
simultaneously support multiple domains. 
Work on multiple domains at the language 
level 10 should provide a basis for multi- 
domain environments. 

Mechanisms. A variety of mechanisms 
and classes of mechanisms have formed 
the basis of many successful prototype and 
production environments. Examples 
include both incremental algorithms, such 
as Reps’s attribute grammar evaluation 
scheme, 11 that provide one of the key 
underpinnings of interactive environments 
and also advances in user interface tech¬ 
nology, such as those that arise from the 
early experiences with Smalltalk, that pro¬ 
vide a solid basis for much of the external 
appearance of environments. 

There are several specific areas where 
additional mechanisms more appropriate 
to environments are needed. One of these 
areas is database support, as Bernstein has 
so clearly shown. 12 Rich type models, 
multiple representations, and versioning 
are just some of the characteristics that 
existing database and file systems do not 
support in a suitable way for environ¬ 
ments. Another area is tool integration. 
Constructing and evolving tools in inter¬ 
active environments is extraordinarily dif¬ 
ficult, since the interactions among the 
tools must generally be dealt with 
explicitly. Although progress is being 
made by several research groups, no model 
as simple and ubiquitous as Unix pipes has 
yet been developed. (Some representations 
of software entities, such as abstract syn¬ 
tax trees and program dependency graphs 
are widely used in environments; however, 
general tool integration mechanisms that 
allow these representations to be easily 
glued together into environments are still 
lacking.) Taken together, these mechan¬ 
isms form the basis for an environment 
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architecture, which provides a platform in 
which constructing environments is 
qualitatively simpler than is currently pos¬ 
sible. Research on individual mechanisms 
and on complete environment architec¬ 
tures is necessary. 

Evaluation. Perhaps the biggest failing 
of environments research and develop¬ 
ment to date is the general lack of scientific 
evaluation of existing environments. 
Evaluation approaches and actual evalu¬ 
ations are beginning to appear, 13 but rela¬ 
tively little effort has been given to this 
undeniably fundamental subject. 

Despite listing this as a shortcoming, it 
is important to note that, for several rea¬ 
sons, evaluation of environments is diffi¬ 
cult. First, useful qualitative analysis of 
programmer productivity and software 
quality improvements are hard to produce; 
similarly, most quantitative analyses do 
not, in and of themselves, provide suffi¬ 
cient information for proper evaluation. 
Second, to effectively evaluate an environ¬ 
ment, one must have a suitably large user 
community; recruiting such a community 
is difficult or impossible in many situa¬ 
tions, especially where the environment is 
intended for multi-person multi-year soft¬ 
ware system development, where the 
evaluation costs would be excessive. 
Third, the design space for environments 
is enormous; hence, comparative evalua¬ 
tion is unwieldy since so many experimen¬ 
tal variables change from environment to 
environment. 

An understanding of the importance of 
evaluation of environments is essential 
before the field can actually produce 
powerful and effective environments. 

T he articles in these companion 
issues address but a portion of 
these problems. Many of the arti¬ 
cles solve important, but still limited, cases 
of the problems. These incremental and 
consistent strides towards solving the key 
problems in environments show that the 
field has significant potential for meeting 
its goal of improving the productivity and 
quality of software developers and of 
software. 14,I5 D 
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architecture, which provides a platform in 
which constructing environments is 
qualitatively simpler than is currently pos¬ 
sible. Research on individual mechanisms 
and on complete environment architec¬ 
tures is necessary. 


staff — in particular, Margie Ramsdell of the 
University of Washington and Kathy Germana 
of SUNY at Stony Brook — who helped man¬ 
age the many details that had to be handled. 
Everyone involved — including editors, 
authors, referees, and staff — did a great job 
while working under time pressures that were 
always great and often unreasonable. 


Evaluation. Perhaps the biggest failing 
of environments research and develop¬ 
ment to date is the general lack of scientific 
evaluation of existing environments. 
Evaluation approaches and actual evalu¬ 
ations are beginning to appear, 13 but rela¬ 
tively little effort has been given to this 
undeniably fundamental subject. 

Despite listing this as a shortcoming, it 
is important to note that, for several rea¬ 
sons, evaluation of environments is diffi¬ 
cult. First, useful qualitative analysis of 
programmer productivity and software 
quality improvements are hard to produce; 
similarly, most quantitative analyses do 
not, in and of themselves, provide suffi¬ 
cient information for proper evaluation. 
Second, to effectively evaluate an environ¬ 
ment, one must have a suitably large user 
community; recruiting such a community 
is difficult or impossible in many situa¬ 
tions, especially where the environment is 
intended for multi-person multi-year soft¬ 
ware system development, where the 
evaluation costs would be excessive. 
Third, the design space for environments 
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Software Development 
Environments 

Susan A. Dart, Robert J. Ellison, Peter H. Feiler, and A. Nico Habermann 
Carnegie Mellon University 


^ ^ "■’l nvironment” refers to the 
■H collection of hardware and 
MmJi software tools a system 
developer uses to build software systems. 
As technology improves and user expecta¬ 
tions grow, an environment’s functional¬ 
ity tends to change. Over the last 20 years 
the set of software tools available to 
developers has expanded considerably. 

We can illustrate this change by observ¬ 
ing some distinctions in the terminology. 
“Programming environment” and “soft¬ 
ware development environment” are often 
used synonymously, but here we will make 
a distinction between the two. By “pro¬ 
gramming environment” we mean an 
environment that supports only the coding 
phase of the software development 
cycle—that is, programming-in-the-small 
tasks such as editing and compiling. By 
“software development environment” we 
mean an environment that augments or 
automates all the activities comprising the 
software development cycle, including 
programming-in-the-large tasks such as 
configuration management and 
programming-in-the-many tasks such as 
project and team management. We also 
mean an environment that supports large- 
scale, long-term maintenance of software. 

The evolution of environments also 
demands that we distinguish basic operat¬ 
ing system facilities—fundamental ser- 


j 

A taxonomy of software 
development 
environments reveals 
trends in their 
evolution. 


vices such as memory, data, and multiple- 
program management—from the en¬ 
hanced functionality that characterizes 
state-of-the-art environments. This en¬ 
hanced functionality is typically achieved 
through tools such as browsers, window 
managers, configuration managers, and 
task managers. In a sense, environments 
have evolved in concert with the software 
engineering community’s understanding 
of the tasks involved in the development 
of software systems. 

To better understand the technological 
trends that have produced state-of-the-art 
environments, we here present a taxonomy 
of these trends. We cite examples of 
research and commercial systems within 


each class. We intend the taxonomy to 
show the direction of the trends and to sug¬ 
gest where more work needs to be done. 

The taxonomy comprises four categor¬ 
ies, each representing trends having a sig¬ 
nificant impact on environments—on their 
tools, user interfaces, and architectures. 
The four categories are 

• Language-centered environments. 
These are built around one language, 
thereby providing a tool set suited to that 
language. These environments are highly 
interactive and offer limited support for 
programming-in-the-large. 

• Structure-oriented environments. 
These incorporate techniques that allow 
the user to manipulate structures directly. 
The language independence of the tech¬ 
niques led to the notion of generators for 
environments. 

• Toolkit environments. Theseprovide 
a collection of tools that includes 
language-independent support for 
programming-in-the-large tasks such as 
configuration management and version 
control. There is little, if any, 
environment-defined control and manage¬ 
ment of tool usage. 

• Method-based environments. These 
incorporate support for a broad range of 
activities in the software development 
process, including tasks such as team and 
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project management (programming-in- 
the-many). These environments also incor¬ 
porate tools for particular specification 
and design methods. 

We could discuss the trends from several 
perspectives. For example, we could take 
a tool builder’s perspective, focusing on 
techniques for tool integration. We could 
take an expert system builder’s perspec¬ 
tive, focusing on the automation of the 
software development process by means of 
a programmer’s assistant that uses 
knowledge-based concepts. However, we 
discuss the trends from the user’s perspec¬ 
tive; that is, we examine how the trends 
affect the user’s perception of, and inter¬ 
action with, an environment. 

User requirements for environments 
cover a broad spectrum. The functional¬ 
ity of environments includes support for 
a single user for programming-in-the- 
small, coordination and management of 
multiple users for programming-in-the- 
large, and management of the software 
development cycle. The nature of the user 
interface is of considerable importance. 
Undoubtedly, the user of an environment 
needs to be able to customize it, either by 
tailoring or extending a particular tool or 
by creating specialized tools via generation 
facilities. To support this, the environment 
must be implemented so as to allow tools 
to be easily integrated into it. The user also 
needs facilities to support incremental 
development of software to aid prototyp¬ 
ing. In essence, the user requires support 
for the entire software development 
cycle—from specification through coding 
to maintenance—including the ability to 
trace information across phases. This 
spectrum of needs is addressed across all 
the categories of our taxonomy, though no 
single category deals with them all. 

We do not attempt to survey all existing 
environments nor do we provide detailed 
descriptions or evaluations of them. Nei¬ 
ther do we advocate any particular envi¬ 
ronment. In fact, because users have 
varying levels of expertise, different appli¬ 
cation requirements, and different hard¬ 
ware, no single environment can satisfy all 
users. 

The significance of our taxonomy is in 
its clarification of trends rather than in 
categorization of particular environments. 
A particular environment may fit into a 
number of categories. These categories do 
not represent competing viewpoints; 
instead, they represent areas of effort that 
have provided fertile feedback and 
inspired further research and devel¬ 
opment. 


Language-centered 

environments 

Language-centered environments are 
those in which the operating system and 
tool set are specially built to support a par¬ 
ticular language. Examples of language- 
centered environments are Interlisp for the 
Lisp language, Cedar for Mesa/Cedar, 
Smalltalk for Smalltalk, and the Rational 
Environment for Ada. Initial implemen¬ 
tations of Lisp environments emerged in 
the late 1960s. Researchers at Xerox 
worked concurrently on the Cedar, 
Smalltalk, and Interlisp environments in 
the mid-1970s. The Lisp activities culmi¬ 
nated in the early 1980s with the definition 
of the Common Lisp language. The 
Rational Environment emerged in the 
early 1980s. 

Lisp environments were the most 
influential in the development of tech¬ 
niques suited for language-centered envi¬ 
ronments. They contributed the notion of 
an exploratory style of programming and 
demonstrated the benefits of making 
semantic information available to the user. 
Subsequent environments for imperative 
languages extended these notions toward 
supporting programming-in-the-large to 
meet large-scale software development 
requirements. 

Exploratory style. Environments in the 
language-centered category encourage an 
exploratory style of programming to aid 
rapid production of software. The devel¬ 
opment environment and the runtime 
environment are the same. Code can be 
developed, executed, tested, debugged, 
and changed quickly; small code changes 
can be made executable in a matter of 
seconds. Programs can be built interac¬ 
tively in increments, allowing the user to 
experiment with software prototypes. 
Implementation techniques for these envi¬ 
ronments result in a coupling between the 
application program and the environment. 
This coupling makes all the facilities of the 
environment available to the user building 
an application. 

Language-centered environments use 
language-specific implementation tech¬ 
niques. To support the rapid production 
of software for research prototypes, Inter¬ 
lisp uses a large virtual memory space, for 
example. The tools are engineered as a 
monolithic system in one address space, 
and the application program is embedded 
in the same address space. Thus, the envi¬ 
ronment does not need to context-switch 


between tools and the application pro¬ 
gram. Execution of the application pro¬ 
gram can be halted, and changes can be 
made to sources that are then dynamically 
linked into the executable image. Such use 
of memory created the need for garbage 
collection of unused, expired objects. 

The embedding of the application in 
environment code allows the application 
writer to use all the facilities in the environ¬ 
ment when constructing an application. 
Since the environment and the application 
program share the same language, the 
application has all the features of the envi¬ 
ronment available to it as building blocks. 
For example, Interlisp is a “residential sys¬ 
tem” in which the Lisp program resides in 
the runtime system as a data structure. 1 
As a result, the user is able to quickly pro¬ 
totype an application by reusing code 
available as part of the environment. In the 
same manner, the user is able to extend the 
environment with tools to satisfy specific 
needs. This approach is particularly evi¬ 
dent in Smalltalk, in which the user can 
create objects and operations that default 
to or inherit the properties of other 
objects. 

Since the close coupling of application 
and environment results in a lack of clear 
separation between the host environment 
and the target runtime environment, in 
cases such as cross-machine development 
special efforts have to be made to deliver 
an application program without the full 
development environment. 

Semantic information. Language- 
centered environments support the 
exploratory, interactive mode of program¬ 
ming by recording and making available 
semantic information. Language-centered 
environments maintain syntactic and 
semantic information about programs in 
a particular program representation for¬ 
mat. For example, the Rational Environ¬ 
ment uses a DIANA format to represent 
Ada programs. It creates this structure 
when parsing program text and attaches 
semantic properties to the structure. 
Semantic information is typically symbol- 
table information such as information 
about the definition and use of variables 
and procedures and information about 
types. By making this information avail¬ 
able through such tools as browsers, the 
environment helps the user understand the 
status and structure of code under devel¬ 
opment. Browsing involves navigating 
through the set of program objects (func¬ 
tions or modules, for example) and mak¬ 
ing queries about the objects and their 
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relationships. Interlisp’s Masterscope was 
one of the first browsers to make seman¬ 
tic information available to the user dur¬ 
ing program development. 

Browsers have been accepted as fun¬ 
damental, powerful tools for exploratory 
program development. They also have the 
potential of being very effective during 
program maintenance. Maintainers are 
usually not the original developers of a 
program and often can depend only on the 
source code as the up-to-date documenta¬ 
tion. Before making changes to a large, 
unfamiliar program, maintainers usually 
spend considerable time understanding the 
program structure and the interconnection 
of its components. Browsers help main¬ 
tainers determine the scope of a change by 
allowing them to interactively examine the 
program structure and ask which compo¬ 
nents may be affected by a change. 

Programming-in-the-large. High-level 
programming languages do not ade¬ 
quately support the activities involved in 
constructing large systems. For example, 
Ada provides packages to support 
modularization, but it does not permit 
alternative implementations or successive 
versions of code to be attached to a pack¬ 
age specification. For that reason, 
language-centered environments have 
added facilities to support programming- 
in-the-large. 

Techniques for controlling and manag¬ 
ing multiple versions of modules among 
multiple users have also been developed. 
These techniques inspired more formal 
definitions of version control and config¬ 
uration management. For example, Cedar 
pioneered a paradigm for system model¬ 
ing. It allows the user to define a 
blueprint—that is, a system model. The 
model is a description of the modules that 
make up a program. Given the model, the 
environment can maintain a history of the 
versions of the modules and can assist the 
user’s selection of various versions in 
forming a program. The environment can 
also determine the recompilation needs of 
a program and can recompile modules to 
maintain consistency among them. 

The Rational Environment supports 
multiple users. It provides facilities for 
building and maintaining versions of 
groups of modules (subsystems). It can 
enforce a check-in/check-out procedure 
that prevents programmers from overwrit¬ 
ing each other’s modifications. It also con¬ 
trols access to program components. 

Observations. Language-centered envi¬ 
ronments give the user a one-language uni- 


Language-centered 
environments give the 
user a one-language 
universe of discourse 
and well suit the 
coding phase of the 
software development 
cycle. 


verse of discourse. These environments are 
well-suited to the coding phase of the soft¬ 
ware development cycle. They provide 
incremental compilation or interpretation 
techniques to help reduce the impact of 
small code changes during maintenance. 
The exploratory style of programming 
they support helps the user experiment 
with software prototypes. Tools such as 
browsers not only are extremely helpful to 
the user during exploratory program 
development but can be quite effective for 
maintenance of large software systems. 

Because of the specialized techniques 
used to implement them, these environ¬ 
ments generally do not support multiple 
languages and, in some cases, do not facili¬ 
tate the porting of application programs. 
Also, language-centered environments can 
become too large for one person to com¬ 
prehend and extend. 

The environments for imperative lan¬ 
guages support programming-in-the-large 
facilities such as version control. But they 
do not currently support programming-in- 
the-many tasks such as project manage¬ 
ment nor do they provide support for 
development tasks other than coding. It is 
not clear whether such environments can 
scale up their facilities to fulfill these 
requirements, but they will probably form 
one component of future environments 
that will support the entire software life 
cycle. The specialized, handcrafted nature 
of these environments makes it difficult to 
adapt them to phases other than coding. 

Developers of commercial software sys¬ 
tems are trying to refine their implemen¬ 
tation techniques to improve perfor¬ 
mance. They are building language- 
centered environments for imperative lan¬ 
guages such as C and Modula-2 and are 


attempting to scale up these environments 
to support the design phase and to incor¬ 
porate some project management tech¬ 
niques. The research community is 
applying language-centered techniques to 
languages such as Prolog and to specifica¬ 
tion languages. Commercial application 
builders so far have used language- 
centered environments mainly for 
developing prototype systems. 


Structure-oriented 

environments 

The initial motivation for structure- 
oriented environments was to give the user 
an interactive tool—a syntax-directed 
editor—for entering programs in terms of 
language constructs. This capability was 
extended to provide single-user program¬ 
ming environments that support interac¬ 
tive semantic analysis, program execution, 
and debugging. The editor is the central 
component of such environments; it is the 
interface through which the user interacts 
and through which all structures are 
manipulated. Efforts were continued to 
support programming-in-the-small and 
programming-in-the-large and to support 
structures such as history logs and access 
control lists. Thus the term “syntax- 
directed” has gradually been replaced by 
“structure- oriented.” 

Structure-oriented environments have 
made several contributions to environ¬ 
ment technology—they have provided 
direct manipulation of program struc¬ 
tures, multiple views of programs gener¬ 
ated from the same program structure, 
incremental checking of static semantics 
and semantic information accessible to the 
user, and, most important, the ability to 
formally describe the syntax and static 
semantics of a language from which an 
instance of a structure editor can be 
generated. 

Manipulation of structure and text. 

Structure-oriented environments support 
the concept of direct structure manipula¬ 
tion. The user interacts directly with pro¬ 
gram constructs and avoids the tedium of 
remembering the details of the syntax. 
While program text is displayed on the 
screen, the user directly modifies the 
underlying structure. Early environments 
such as Emily used parse trees as program 
structures. Most current environments use 
abstract syntax trees, which were intro¬ 
duced in the Mentor environment. 
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Structure-oriented environments take 
several approaches to the manipulation of 
structures. One involves purely structural 
editing; it can be viewed as primarily 
template-driven editing. An example of 
this approach is the Aloe editor in the Gan- 
dalf project. Aloe provides editing oper¬ 
ations only on structural elements and 
does not permit the user to construct syn¬ 
tactically incorrect programs. To over¬ 
come the difficulties in entering and 
modifying language expressions, some 
environments such as the Cornell Program 
Synthesizer represent expressions as text. 

Another approach is mixed-mode oper¬ 
ation, which is being used in several com¬ 
mercial structure-oriented environments. 
For example, in the Rational Environment 
the user can operate on the textual repre¬ 
sentation and on the structure. The user 
enters program fragments as text and asks 
the environment to complete the process¬ 
ing as far as possible. Using incremental 
parsing techniques, 2 the environment 
converts the text fragment into a program 
structure. The user can edit the program 
using commands applied to both the pro¬ 
gram structure and the program text. The 
environment keeps the two representations 
consistently updated. 

Multiple views of program structures. 

Structure-oriented environments generate 
the textual representation of a program 
from its structure. Thus, different 
representations can be generated from the 
same structure. This property allows users 
of structure-oriented environments to view 
programs at different levels of abstraction 
and detail. Browsing of large program 
structures is provided by showing views of 
different levels of detail in different dis¬ 
play windows. The user can select a pro¬ 
gram component in one window and have 
it displayed in more detail in another. This 
capability can be found in research envi¬ 
ronments such as the Gandalf prototype 
and in commercial products such as the 
Rational Environment. Moreover, 
research prototypes such as the Pecan 
environment have demonstrated that it is 
feasible to produce graphical representa¬ 
tions from program structures. 

Semantics and incremental processing. 

After the first syntax-directed editors were 
built, it was quickly recognized that 
enforcing correct syntax is only one way of 
supporting the programmer. Analysis of 
static semantics was added to editors. The 
semantic analyzer processes the program 
structure and decorates it with semantic 
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information. The user can access the 
semantic information—such as the defi¬ 
nition of identifiers and the locations of 
their use—and type information through 
the editor. For example, as the user pro¬ 
grams a procedure call, the editor can dis¬ 
play the specification of the procedure 
and, as soon as the procedure name has 
been entered, provide a template for the 
procedure parameters. 

A structure-oriented environment is an 
interactive tool. Therefore, it should not 
only give the user immediate feedback on 
syntax errors but also report static seman¬ 
tic errors before the user moves on to edit 
other parts of the program. This means 
that the environment must track the user’s 
changes to the program (that is, know its 
structure) and reanalyze only those parts 
that are affected, doing this upon explicit 
user request or when the user leaves the 
modified program unit. Proven compiler 
technology, such as attribute grammars, 
has been successfully extended to support 
such incremental processing. Environ¬ 
ments such as LOIPE demonstrate that the 
notion of incremental processing can also 
be applied to code generation and linking. 
There is a trade-off between processing as 
small a unit as possible and the complex¬ 
ity of the algorithm for doing so. Differ¬ 
ent types of processing can be done at 
different levels of granularity. For exam¬ 
ple, syntactic correctness can be enforced 
at the language construct level while static 
semantics is checked at the program unit 
level (at the level of a procedure, for exam¬ 
ple) and code is generated at the module 
level. 

Generation of structure-oriented envi¬ 
ronments. One of the major contributions 


of structure-oriented environments is their 
ability to support manipulation of pro¬ 
gram structures in a language-independent 
manner. The environment developer 
achieves this by encapsulating the syntac¬ 
tic and semantic properties of a language 
in a grammar. Given this declarative 
description of the language, generation 
tools can automatically produce instances 
of structure-oriented environments. This 
is more efficient than building an environ¬ 
ment from scratch. Proven compiler tech¬ 
nology such as parser generation has paved 
the way for progress in this area. The Aloe 
editor introduced the capability of describ¬ 
ing the syntax of a language. The Cornell 
Synthesizer Generator is a well-known 
example of supporting the description of 
semantic properties in terms of attribute 
grammars, and of providing incremental 
analysis algorithms as part of the gener¬ 
ated structure-oriented environment 
instance. 

The language-specific information can 
be kept in a form that can be loaded into 
the language-independent environment 
kernel at runtime, permitting one instance 
of the structure-oriented environment to 
understand several program structures 
simultaneously. The environment can be 
adapted and tailored through changes in 
the declarative description. 

Observations. Structure-oriented envi¬ 
ronments support direct manipulation and 
multiple textual views of program struc¬ 
tures. Research has shown how static 
semantic information can be attached to 
program structures and made available to 
the user. Algorithms that can incremen¬ 
tally analyze this information have been 
developed. Instances of structure-oriented 
environments can be generated automat¬ 
ically from descriptions of the language to 
be supported. These descriptions specify 
both syntactic and static semantic infor¬ 
mation in a declarative manner. 

Structure-oriented environments have 
become mature enough that they are 
becoming available in commercial 
products. Environment builders can 
generate instances of structure editors for 
different languages with little effort. In 
many cases, the capabilities of these gener¬ 
ated editors are restricted to syntactic 
checking. Semantic analyzers are often 
constructed manually. 

Structure-oriented environments have 
been accepted primarily as teaching aids. 
Universities have been using them to teach 
introductory programming courses. 
Despite their availability, they have found 
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A sampler of software development environments 


Listed here are the languages, methods, and environments 
discussed in this article. They are grouped into the four cate¬ 
gories of our taxonomy; a citation to the literature appears for 
each. 


Language-centered environments 

Ada 

Ada Programming Language, American National Standards 
Institute, New York, 1983. 

Cedar 

D.C. Swinehart, PT. Zellweger, and R.B. Hagmann, “The 
Structure of Cedar,” SIGPIan Notices (Proc. ACM SIGPIan 
Symp. Language Issues in Programming Environments), July 
1985, pp. 230-244. 

Common Lisp 

G.L. Steele, Jr., Common Lisp—The Language, Digital Press, 
Burlington, Mass., 1984. 

DIANA 

G. Goos et al., eds., DIANA—An Intermediate Language for 
Ada (Lecture Notes in Computer Science, Vol. 161), Springer- 
Verlag, Berlin, 1983. 

Interlisp 

W. Teitelman and L. Masinter, “The Interlisp Programming 
Environment,” in Tutorial: Software Development Environ¬ 
ments, Computer Society Press, Los Alamitos, Calif., 1981, pp. 
73-81. 

Rational Environment 

J.E. Archer, Jr., and M.T. Devlin, “Rational’s Experience 
Using Ada for Very Large Systems,” Proc. First Int’l Conf. Ada 
Programming Language Applications for the NASA Space Sta¬ 
tion, NASA, June 1986, pp. B2.5.1-B2.5.12. 

Smalltalk 

A. Goldberg, “The Influence of an Object-oriented Language 
on the Programming Environment,” in Interactive Program¬ 
ming Environments, D.R. Barstow, H.E. Shrobe, and E. San- 
dewall, eds., McGraw-Hill, New York, 1984, pp. 141-174. 


Structure-oriented environments 

Aloe 

P.H. Feilerand R. Medina-Mora, “An Incremental Program¬ 
ming Environment,” IEEE Trans. Software Engineering, Sept. 
1981, pp. 472-482. 

Cornell Program Synthesizer 
T. Reps and T. Teitelbaum, “The Synthesizer Generator,” 
SIGPIan Notices (Proc. ACM SIGSoft/SIGPIan Software 
Engineering Symp. on Practical Software Development Envi¬ 
ronments), May 1984, pp. 42-48. 

Emily 

W.J. Hansen, “User Engineering Principles for Interactive 
Environments,” in Interactive Programming Environments, 


D.R. Barstow, H.E. Shrobe, and E. Sandewall, eds., McGraw- 
Hill, New York, 1984, pp. 217-231. 

Gandalf 

A.N. Habermann and D. Notkin, “Gandalf: Software Devel¬ 
opment Environments,” IEEE Trans. Software Engineering, 

Dec. 1986, pp. 1117-1127. 

LOIPE 

D. Notkin, “The Gandalf Project,” J. Systems and Software, 
May 1985, pp. 91-105. 

Mentor 

V. Donzeque-gouge et al., “Programming Environments 
Based on Structured Editors: The Mentor Experience,” in Inter¬ 
active Programming Environments, D.R. Barstow, H.E. Shrobe, 
and E. Sandewall, eds., McGraw-Hill, New York, 1984, pp. 
128-140. 

Pecan 

S.P. Reiss, “Graphical Program Development with PECAN 
Program Development Systems,” SIGPIan Notices (Proc. ACM 
SIGSoft/SIGPIan Software Engineering Symp. on Practical 
Software Development Environments), May 1984, pp. 30-41. 


Toolkit environments 

Apollo DSEE 

D.B. Leblang and R.P. Chase, Jr., “Computer-aided Software 
Engineering in a Distributed Workstation Environment,” SIG¬ 
PIan Notices (Proc. ACM SIGSoft/SIGPIan Software Engineer¬ 
ing Symp. on Practical Software Development Environments), 
May 1984, pp. 104-112. 

Arcadia 

R.N. Taylor et al., Arcadia: A Software Development Environ¬ 
ment Research Project, tech, report, Univ. of California, Irvine, 
Mar. 1986. 

CAIS 

Military Standard Common APSE Interface Set, Proposed 
MIL-STD-CAIS, Ada Joint Program Office, Washington, D.C., 
Jan. 1985. 

PCTE 

F. Gallo, R. Minot, and I. Thomas, “The Object Management 
System of PCTE as a Software Engineering Database Manage¬ 
ment System,” SIGPIan Notices (Proc. Second ACM SIG¬ 
Soft/SIGPIan Software Engineering Symp. on Practical 
Software Development Environments), Jan. 1987, pp. 12-15. 
Unix/PWB 

T.A. Dolotta, R.C. Haight, and J.R. Mashey, “Unix Time-shar¬ 
ing System: The Programmer’s Workbench,” in Interactive Pro¬ 
gramming Environments, D.R. Barstow, H.E. Shrobe, and E. 
Sandewall, eds., McGraw-Hill, New York, 1984, pp. 353-369. 

VMS VAXset CMS 

User's Introduction to VAX DEC/CMS, Digital Equipment 
Corp., Maynard, Mass., 1984. 
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Method-based environments 

Anna 

D. Luckham and F.W. von Henke, “An Overview of Anna, A 
Specification Language for Ada," IEEE Software, Mar. 1985, 
pp. 9-22. 

CORE 

G.P. Mullery, “CORE—A Method for Controlled Requirement 
Specification,” Proc. 4th Int’l Conf. on Software Engineering, 
Computer Society Press, Los Alamitos, Calif., 1979, pp. 

126-135. 

DCDS 

G.E. Sievert and T.A. Mizell, “Specification-based Software 
Engineering with TAGS,” Computer, Apr. 1985, pp. 56-66. 
Entity-relationship (ER-Chen) diagrams 
P. Chen, “The Entity-Relationship Model—Toward a Unified 
View of Data,” ACM Trans, on Database Systems, Mar. 1976, 
pp. 9-36. 

Excelerator 

Index Technology Corp., “Excelerator,” Proc. Computer- 
aided Software Engineering Symp., Digital Consulting Inc., 
Andover, Mass., June 1987. 

Genesis 

C. V. Ramamoorthy et al., “Genesis: An Integrated Environ¬ 
ment for Supporting Development and Evolution of Software,” 
Proc. Compsac 85, Computer Society Press, Los Alamitos, 
Calif., 1985, pp. 472-479. 

GIST 

S.F. Fickas, “Automating the Transformational Development 
of Software,” IEEE Trans. Software Engineering, Nov. 1985, pp. 
1268-1277. 

IORL 

G.E. Sievert and T.A. Mizell, “Specification-based Software 
Engineering with TAGS,” Computer, Apr. 1985, pp. 56-66. 

IPSE 2.5 

D. Morgan, “The Imminent IPSE,” Datamation, Apr. 1987, pp. 
60-64. 

ISTAR 

M. Dowson, “ISTAR—An Integrated Project Support Environ¬ 
ment,” SIGPIan Notices (Proc. Second ACM SIGSoft/SIGPIan 
Software Engineering Symp. on Practical Software Develop¬ 
ment Environments), Jan. 1987, pp. 27-33. 

PSL/PSA 

D. Teichroew and E.A. Hershey III, “PSL/PSA: A Computer- 
aided Technique for Structured Documentation and Analysis 
of Information Processing Systems,” IEEE Trans. Software 
Engineering, Jan. 1977, pp. 41-48. 

Leonardo 

W. Myers, “MCC: Planning the Revolution in Software,” IEEE 
Software, Nov. 1985, pp. 68-73. 

Merise diagrams 

Pham Thu Ouang, “Merise: A French Methodology for Infor¬ 
mation Systems Analysis and Design,” J. Systems Manage¬ 
ment, Mar. 1986, pp. 21-24. 


Nastec CASE 2000 

Nastec Corp., “Nastec CASE 2000,” Proc. Computer- aided 
Software Engineering Symp., Digital Consulting Inc., Andover, 
Mass., June 1987. 

PMA 

L. M. Gilham et al., Project Management in a Knowledge- 
based Software Environment, tech, report KES.U.87.2, Kestrel 
Institute, Palo Alto, Calif., 1987. 

Petri nets 

J.L. Peterson, Petri Net Theory and the Modelling of Sys¬ 
tems, Prentice-Hall, Englewood Cliffs, N.J., 1981. 

Prospectra 

B. Krieg-Brueckner et al., “PROgram Development by SPECi- 
fication and TRAnsformation,” in Esprit 86: Results and 
Achievements, Elsevier Science Pub. Co., New York, 1987, pp. 
301-311. 

Refine 

D.R. Smith, G.B. Kotik, and S.J. Westfold, “Research on 
Knowledge-based Software Environments at Kestrel Insti¬ 
tute,” IEEE Trans. Software Engineering, Nov. 1985, pp. 
1278-1295. 

SADT 

D.T. Ross, “Applications and Extensions of SADT,” Com¬ 
puter, Apr. 1985, pp. 25-35. 

Schematic design methods 
J. Martin and C. McClure, Diagramming Techniques for 
Analysts and Programmers, Prentice-Hall, Englewood Cliffs, 
N.J., 1985. 

SDL 

A. Rockstrom and R. Saracco, “SDL—CCITT Specification 
and Description Language,” IEEE Trans. Communications, 
June 1982, pp. 1310-1318. 

Software Through Pictures 

A.I. Wasserman and P.A. Pircher, “A Graphical, Extensible 
Integrated Environment for Software Development,” SIGPIan 
Notices (Proc. Second ACM SIGSoft/SIGPIan Software 
Engineering Symp. on Practical Software Development Envi¬ 
ronments), Jan. 1987, pp. 131-142. 

SREM 

M. Alford, “SREM at the Age of Eight: The Distributed Com¬ 
puting Design System,” Computer, Apr. 1985, pp. 36-46. 

Teamwork 

Cadre Technology, “Improved Duality and Productivity with 
Teamwork/SA,” System Development, Oct. 1985. 

TAGS 

G.E. Sievert and T.A. Mizell, “Specification-based Software 
Engineering with TAGS,” Computer, Apr. 1985, pp. 56-66. 

VDM 

D. Bjorner, “On the Use of Formal Methods in Software 
Development,” Proc. 9th Int’l Conf. on Software Engineering, 
Computer Society Press, Los Alamitos, Calif., 1987, pp. 17-29. 
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little acceptance in industry. Structure edi¬ 
tors are being used to support only the cod¬ 
ing phase and are being viewed as tools for 
programming-in-the-small. So far, little 
empirical data has been collected to indi¬ 
cate whether structure-oriented environ¬ 
ments actually increase productivity. 

Initial attempts to scale up structure- 
oriented environments to support 
programming-in-the-large and program- 
ming-in-the-many have encountered dif¬ 
ficulties. Techniques currently used in 
many structure-oriented environments 
have shortcomings in terms of providing 
efficient, persistent storage for large struc¬ 
tures and in coordinating concurrent 
access to the structures for multiple users 
or tools. Furthermore, for different tools 
to be integrated in a structure-oriented 
environment, they must either be adapted 
to understand a common structural repre¬ 
sentation or there must be mechanisms for 
consistent updating of structures through 
multiple views. 


Toolkit environments 

Toolkit environments consist of a col¬ 
lection of small tools and are intended 
primarily to support the coding phase of 
the software development cycle. They pro¬ 
vide little environment-defined control or 
management over the ways in which the 
tools are applied. The toolkit approach 
starts with the operating system and adds 
coding tools such as a compiler, editor, 
assembler, linker, and debugger, as well as 
tools to support large-scale software devel¬ 
opment tasks such as version control and 
configuration management. The toolkit 
approach was motivated by the need to be 
language-independent while supporting 
programming-in-the-large facilities. The 
toolkit approach uses simple data model¬ 
ing to aid the extensibility and portability 
of tools. Examples of commercial toolkit 
systems are the Unix Programmer’s Work¬ 
bench (Unix/PWB), the DEC VMS VAX- 
set, and the Apollo Domain Software 
Engineering Environment (DSEE). Exam¬ 
ples of prototype toolkit environments are 
the Portable Common Tool Environment 
(PCTE) and the Common APSE Interface 
Set (CAIS). 

Extensibility and portability. Unix is an 
operating system that has encouraged 
extensions. It has a very simple data model 
for tool interaction and persistent data 
storage: an ASCII byte stream. This uni- 



Commercial 
environment builders 
are placing higher-level 
interfaces on top of 
the normal operating 
system user-command 
interface. 


form model enables the user to tailor the 
Unix environment by adding new tools or 
modifying existing ones. Tools interact via 
ASCII files or communication channels 
called pipes, which encourages reuse of 
existing tools and tool fragments. Each 
tool or tool fragment must parse the text 
stream to extract a structured representa¬ 
tion of the data; that is, no structure or 
semantic information is recorded with the 
data. This results in tools with few 
incremental processing capabilities. The 
Unix/PWB places few, if any, restrictions 
on when and how tools can be used. Such 
a model gives the user considerable lati¬ 
tude but provides little support in terms of 
consistently and automatically managing 
user activities. The simplicity of the tools 
and their interactions makes them porta¬ 
ble across similar environments. 

The simple ASCII model lacks support 
for typing stored data and for uniformly 
describing and processing the structure of 
data. It provides very limited typing of 
objects other than the use of file name 
extensions. Developments are in progress 
to extend file systems to include some of 
this support. Apollo’s Extensible Stream 
package provides a mechanism that sup¬ 
ports typed files and permits the introduc¬ 
tion of user-defined file types. DSEE has 
facilities embedded in its file system to pro¬ 
vide a version control mechanism that is 
transparent to the environment user and 
the tools. Environments such as PCTE 
and CAIS support persistent, typed 
objects with an extensible set of object 
attributes, while the Arcadia research 
project addresses tool integration and 
extensibility as well as object management. 

Operating system extensions. To pro¬ 
vide more environment-defined control 
facilities while retaining tailorability fea¬ 


tures, commercial environment builders 
such as Atherton Technology are placing 
higher-level interfaces on top of the nor¬ 
mal operating system user command inter¬ 
face. Such environments allow the user to 
work within the context of the high-level 
functions of the environment, such as 
those for project management, but also to 
jump into the native operating system 
command level, such as that for Unix or 
VMS, when needed. These higher-level 
“shells” try to place more controls on tool 
usage in toolkit environments. They can 
also provide a uniform interface indepen¬ 
dent of the underlying operating system. 
Not only can the user be shielded from the 
operating system itself but he or she can 
have transparent access to distributed 
computing facilities. Similarly, the user 
can add new tools to the toolkit environ¬ 
ment without needing to have a knowledge 
of the underlying hardware and operating 
system. 

Programming-in-the-large. Toolkit 
environments provide programming-in- 
the-large tools that are independent of a 
particular programming language. These 
tools try to ease the programmer’s manag¬ 
ing of code by providing mechanisms for 
recording version numbers for source 
code. Some file systems append a version 
number to a file name and increment it 
each time the file is rewritten. The 
Unix/PWB and VMS VAXset provide 
explicit tools—the SCCS (Source Code 
Control System) and the CMS (Code 
Management System), respectively—to 
perform version control. Such tools sim¬ 
ply record versions and coordinate access 
to them; the user must decide how to use 
the version information. For configura¬ 
tion management, systems such as DSEE 
build a consistent software system as 
described and requested by the user. 

Observations. Toolkit environments use 
operating system facilities to “glue” tools 
into a collection. The intent is to provide 
a language-independent environment that 
supports multiple languages with appro¬ 
priate tools. Such environments allow a 
high degree of tailoring but provide few 
environment-defined management or con¬ 
trol techniques for using the collection of 
tools. The user must establish manage¬ 
ment policies to ensure that tools will be 
used correctly. Although very popular 
because of the tailorability and portabil¬ 
ity of their tools, toolkit environments do 
not greatly assist the maintenance of large 
software systems. 
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The current generation of toolkit envi¬ 
ronments uses a fairly mature technology. 
Research on extensions to operating sys¬ 
tems is continuing. Extensions include a 
better data model to support persistent 
storage and distributed data access, and 
uniform operating-system-independent 
user interfaces. 


Method-based 

environments 

Method-based environments each sup¬ 
port a particular method for developing 
software. The methods fall into two broad 
classes: development methods for partic¬ 
ular phases in the software development 
cycle, and methods for managing the 
development process. Development 
methods are those used by individual 
developers in phases such as requirements 
analysis, system specification, and design. 
Methods for managing the process are 
those that support orderly development of 
a software system via product manage¬ 
ment procedures for consistent evolution 
of the product by a number of developers, 
and via models for organizing and manag¬ 
ing people and activities. 

Support for development methods. 

Development methods address various 
steps in the software development cycle. 
They include but are not limited to 
methods for specification, design, valida¬ 
tion and verification, and reuse. Different 
methods exhibit various degrees of formal¬ 
ity: a method may be informal, as in writ¬ 
ten text; semiformal, as in textual and 
graphical descriptions with limited check¬ 
ing facilities; or formal, with an underly¬ 
ing theoretical model against which a 
description can be verified. Examples of 
semiformal methods for specification and 
design are SREM, IORL, CORE, SADT, 
SDL, PSL/PSA, variations of data flow 
diagrams and control flow diagrams, and 
entity-relationship (ER) diagrams. Exam¬ 
ples of more formal methods for specifi¬ 
cation are Petri nets, state machines, and 
specification languages such as GIST, 
Refine, VDM, and Anna. While several of 
the semiformal methods have been prac¬ 
ticed to some degree since the mid-1970s, 
formal methods are less used. In many 
cases, they were initially practiced with 
paper and pencil. 

Originally, tools for development 
methods were provided on mainframes 
and textual notations or special graphics 
terminals were used. Examples of such sys- 
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terns are TAGS and DCDS. The availabil¬ 
ity of computers to a larger number of 
developers and the advent of affordable 
graphical facilities on personal computers 
and workstations have encouraged the 
development of a large number of com¬ 
mercial tools— especially for semiformal 
methods of schematic design—often called 
computer-aided software engineering, or 
CASE, tools. Examples of such products 
are Index Technology’s Excelerator, 
Nastec’s CASE 2000, Cadre’s Teamwork, 
and Interactive Development Environ¬ 
ments’ Software Through Pictures. Such 
tools support individual users in drawing 
and updating graphical designs interac¬ 
tively, help organize the design into a hier¬ 
archy of abstraction levels, and perform 
certain consistency checks. Users can 
invoke analyzers such as level checkers 
that check for consistent use of names and 
for connections between levels of the 
design. Cross-reference information is 
derived by the analyzer (in most cases not 
incrementally) and is stored in data dic¬ 
tionaries that can be queried interactively. 

Many CASE vendors have realized that 
it is desirable for their tool to support more 
than one design method and for customers 
to adapt the tool to their own methods. 
Recent releases of commercial tools allow 
users to define their own graphical sym¬ 
bols for the graphical editor and to write 
and interface their own analyzers. In some 
cases, instances of a tool can be generated 
for different methods. Integration of 
different methods is limited to instances of 
graphical editors and analyzers that can be 
invoked from the same system menu. For 
methods that differ only in the shape of 
symbols, such as Merise diagrams and ER- 
Chen diagrams, a tool can display the 
design with either set of symbols. All 
instances of the tool store the cross¬ 


reference information in the same data dic¬ 
tionary. 

Support for managing the development 
process. Managing software development 
consists of managing the product under 
development as well as managing the pro¬ 
cess for developing and maintaining the 
product. Support of product management 
includes facilities for version, configura¬ 
tion, and release management along with 
procedures and standards for performing 
these tasks consistently. Support for 
managing the development process 
includes facilities for project management 
(project planning and control), task 
management (helping developers organize 
and track their tasks), communication 
management (knowing and controlling the 
communication patterns in the project 
organization), and process modeling. 

Initially, tools to support particular 
management functions such as scheduling, 
cost estimation, or change request control 
were built in isolation. Recently, research 
has tried to take a more global approach 
to understanding and formalizing the soft¬ 
ware development process and its manage¬ 
ment. This is evidenced in the literature. 3 " 5 
Research prototypes of environments such 
as IPSE 2.5, Genesis, and PMA inves¬ 
tigate the feasibility of supporting various 
aspects of encoding and supporting a proc¬ 
ess model. ISTAR, a commercial develop¬ 
ment, centers the environment around a 
particular model—the contract model— 
rather than around a particular tool. The 
environment supports planning and 
management of tasks and management of 
products as they are being built by teams 
of developers. It also provides facilities to 
integrate specification, design, coding, 
testing, and documentation tools. One of 
the challenges for such environments is to 
support process models and management 
styles without disturbing those in place at 
a particular organization. The practicality 
of such environments has yet to be shown. 

Observations. Method-based environ¬ 
ments support particular development 
methods and the management of the devel¬ 
opment process. A number of tools for 
single users that support semiformal 
graphical development methods have 
become available. Instead of encoding 
particular methods in these tools, their 
developers have engineered them to be 
more general purpose. Instances of design 
tools can be created through a tailoring 
and generation process. Generally, iso¬ 
lated tools are available to support version 
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and configuration management and proj¬ 
ect management. 

The distance between existing tools and 
those of an ideal software development 
environment is great. Progress must occur 
in several areas and these are the target of 
long-term research activities. Research 
efforts such as MCC’s Leonardo project 
are investigating the feasibility of bringing 
the exploratory style of language-centered 
environments to specification and design 


environments. This requires a better 
understanding of the specification and 
design process and the development of for¬ 
mal methods that appropriately capture 
information and decisions. A supportive 
environment must capture and reason 
about the semantics embedded in the 
method, and must process information 
incrementally to assist the designer in 
exploring design alternatives. A better for¬ 
mal understanding of the derivation of 


efficient implementations from a specifi¬ 
cation permits more automation of this 
process. Research in formal and executa¬ 
ble specifications, program transforma¬ 
tions, and program synthesis is making 
progress, but solutions can be expected ini¬ 
tially only in particular application 
domains. Examples of such research 
efforts are the Prospectra project spon¬ 
sored by Esprit and projects at USC/ISI 6 
and Kestrel Institute. 7 Finally, an envi- 


User interfaces 

Major developments in hardware technology such as bit¬ 
mapped displays and mouse devices have made novel user 
interfaces possible. It seems quite natural to use a pointing 
device as the user interface for object-oriented languages 
such as Smalltalk. The Smalltalk language-centered environ¬ 
ment replaces the textual user interface—command lines— 
with pop-up menus, a window manager, and a pointing device, 
thereby providing a very “friendly” interface. On-line tutoring 
is provided by means of tools such as “explain” and “example” 
facilities and through on-line documentation. 

Cedar is also recognized for its user interface, which uses 
techniques similar to those of Smalltalk and incorporates icon 
management. Cedar provides a level of abstraction by defin¬ 
ing an imaging model to handle complex graphics on different 
hardware. This model defines graphic objects by their seman¬ 
tics rather than by their representation. The implementation 
then maps these graphic objects onto the hardware con¬ 
straints. Cedar demonstrates how a nontextual interface can 
be abstracted from the operating system functions. 

In structure-oriented environments, the user interface is 
ruled by the semantics of the language being edited. The Aloe 
editor of the Gandalf project is a prime example of a pure 
structure-oriented editor. For example, when the user gives the 
command if, the editor constructs the if node in the structure, 
displays the template for the /'/construct in the program, and 
places the cursor at the condition of the construct. The syntax 
is enforced because the user can only apply the /'/command 
when the placement of the construct is syntactically correct. 
The user moves the cursor according to the structure. The cur¬ 
sor is shown on the screen as a highlight of the textual area 
that represents the substructure to which the cursor refers. 

For example, moving the cursor up from the condition of an if 
construct highlights the text of the whole if construct. To 
modify existing programs, editing operations such as cut and 
paste and structural transformation operations are provided. 
This allows the user to change, delete, or move syntactic pro¬ 
gram fragments rather than single characters or lines of text. 
Transformation operations allow the user to convert, for exam¬ 
ple, an if statement into a while loop or to nest a sequence of 
statements into a for loop. Despite these editing operations, 
using a purely structural editor to modify expressions is awk¬ 
ward. Therefore, some structure editors (the Cornell Syn¬ 


thesizer, for example) treat expressions as text rather than as 
structure—that is, they allow the expressions to be entered 
and edited as text and then they parse them. 

The Rational Environment works in a mixed mode that 
allows the user to edit a program both structurally and textu- 
ally. After the user enters a program fragment in text form, the 
environment constructs a structure representing the text 
entered and places the cursor at the first place to be com¬ 
pleted. For example, asking the editor to complete the “if” 
results in the construction of the if statement presented. The 
user can move the cursor and edit according to the structure 
(for example, move to the next statement or delete a state¬ 
ment) and according to the text (for example, move down a line 
or delete the rest of the line). 

A technique known as elision displays a marker such as ... 
(three dots) or a label instead of the actual program. Elision 
markers are used to compact source code below a particular 
nesting level. For example, when the user places the cursor at 
the first statement of a procedure, only the specification and 
not the body of the procedure is seen. Constructs such as for, 
while, or if may be similarly compacted. However, when the 
user moves the cursor to the vicinity of an elision marker, the 
text is automatically expanded. 

Browsing is provided in a similar manner. In one window, 
the user sees a high-level view of a program, for example, a list 
of all Ada package names in a program library. The details of 
the packages are hidden. The user can select a package and 
open it for viewing. This results in a textual representation of 
the selected component in more detail in a separate window. 
The user may see, for example, a list of procedure specifica¬ 
tions contained in the package. As before, the user can select 
one of the structural elements and examine it in more detail or 
modify it. 

Method-based environments consisting of CASE tools have 
powerful graphics editing facilities. Interfaces appear similar 
to the menu-based ones for language-centered environments. 
The difference lies in the manipulation of graphical symbols 
based on the syntactical constraints of a particular diagram¬ 
ming technique. Symbols and links can be created, deleted, 
and changed. This is done by positioning the cursor with a 
pointing device and selecting a particular item from the avail¬ 
able menu. 
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ronment that helps manage the develop¬ 
ment process requires research into formal 
models for capturing the process, reason¬ 
ing about it, and supporting the dynamics 
of its execution. 


Conclusions 

The four types of environment in our 
taxonomy represent the major technical 
directions that software development envi¬ 
ronments have taken. We have discussed 
the work in each area primarily from the 
user’s perspective. Language-centered 
environments are interactive, incremental 
environments suited to an exploratory 
style of programming. Structure-oriented 
environments generalize and formalize 
these techniques and provide generators. 
Both types of environments show the 
advantages of making semantic informa¬ 
tion available. Toolkit environments stress 
user tailorability and the reuse of a fairly 
generic tool set, while method-based envi¬ 
ronments concentrate on providing sup¬ 
port for development activities such as 
requirements analysis and design, and 
management activities such as guiding a 
team of programmers during the develop¬ 
ment process. While it would seem 
straightforward to merge these capabilities 
to achieve a highly interactive, tailorable, 
multiple-user, full-life-cycle environment, 
the implementation strategies used for 
each type of environment cannot be eas¬ 
ily combined to produce such a result. We 
conclude by examining what we consider 
to be the primary issues when we try to 
combine or extend the advantages offered 
by each category. 

Data management. Language-centered 
and structure-oriented environments can 
incrementally maintain executable objects 
and static semantic information about 
program units. This functionality is very 
dependent on the underlying program¬ 
ming-language foundations. There are 
formal means to define the language units, 
the constraints on those objects, and the 
relationships between them. Such infor¬ 
mation is used to maintain a consistent 
state after a modification (such as the 
changing of a variable name or the delet¬ 
ing of a statement). 

Method-based environments do not yet 
support such incremental analysis and do 
not seem to have theoretical foundations 
as mature as those of language-centered 
and structure-oriented environments. The 
development methods they support often 


take an operational or control-flow 
approach to the development process. 
Most process models are more oriented to 
managing user activity rather than to 
managing objects. The object manage¬ 
ment architecture used by structure- 
oriented environments is not directly 
applicable to method-based environments. 
It is a research question as to whether it 
should or can be applied. 

The kind of tool integration and 
incremental processing found in structure- 
oriented environments and in many 
language-centered environments depends 
on using a shared data store. The under¬ 
lying representations for those environ¬ 
ments, and for the tools found in the 
method-based environments, are very 
specialized. A generalization of a shared 
data store is a database management sys¬ 
tem. Commercial databases have been 
used to support configuration and project 
management information, but typically 
have not been used for tool-related data 
management. Generalization of the fea¬ 
tures that users like in individual tools in 
the language-centered and method-based 
environments requires a solution to the 
shared data storage problem. The file sys¬ 
tem extensions discussed earlier may offer 
a partial solution to this problem. 

Programming-in-the-large/program- 
ming-in-the-many. As tools for support¬ 
ing development methods become more 
readily available, they are being applied to 
larger projects. This requires scaling up a 
method—that is, incorporating into its 
notation and supporting tools techniques 
for managing large descriptions. Tech¬ 
niques for scaling up are well known in the 
programming language field and appear in 
both the toolkit and language-centered 
environments. They include partitioning 
mechanisms (such as modularization, data 
encapsulation, and interface checking) 
and management mechanisms (such as 
version control). These concepts are not 
used as extensively by the method-based 
environments, which concentrate on the 
operational aspects of the development 
process. The subtasks of the programmer 
are described primarily in terms of actions 
in which information hiding and data 
dependencies play no significant role. The 
issue here may be a simple one of maturity, 
since there is considerable commercial 
activity in this area. 

Tailorability. There are a variety of 
ways to achieve tailorability. Toolkit envi¬ 
ronments take advantage of generic tools 
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defined on relatively unstructured data. In 
the other categories, the information 
maintained is much more complex. Thus, 
tailorability is more likely to be achieved 
by tool generators. For method-based 
environments, we need to consider the 
tailorability of individual tools (such as 
editors) for a specific design method, and 
the tailorability of project or configuration 
management policies. Structure-oriented 
environments provide generators for tools 
such as semantically based editors. Gener¬ 
ators are also appearing in method-based 
environments, where they have been used 
to build graphical editors for a variety of 
design methods. Tailoring the environ¬ 
ment to a specific management policy or 
process development model is more diffi¬ 
cult than tailoring a specific tool and will 
depend on better formalisms for describ¬ 
ing the software process. 

T here has been progress in software 
development environments— 
their support of coding is partic¬ 
ularly well understood. Environments are 
slowly improving, but combining technol¬ 
ogies to better address the entire software 
life cycle remains an area for active 
research. □ 
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Language Processing in 
Program Editors 

Thomas Reps, University of Wisconsin, Madison 
Tim Teitelbaum, Cornell University 


O ne of the most pressing practical 
problems facing computer 
programmers is managing the 
development and maintenance of large 
software systems. This poses a challenge 
for computer scientists: How can com¬ 
puters best be applied to the software- 
development process? 

An important aspect of meeting this 
challenge is to design and implement new 
interactive tools to aid programmers. 
Language-based programming environ¬ 
ments show promise for enhancing the 
power of these tools. Recent work is 
directed toward effective use of specific- 
language knowledge in tools for program¬ 
ming in that language. Such knowledge 
can serve several purposes: 

• Knowledge of the language’s syntax 
can be used to assess whether a program 
contains syntax errors and to determine 
where such errors occur. Syntactic analy¬ 
sis can be either local (to detect context- 
free errors) or global (to detect context- 
sensitive errors). Analysis results displayed 
on the screen provide immediate feedback 
to the programmer developing or modify¬ 
ing the program. By performing syntactic 
analysis and type checking during editing 
rather than compilation, errors may be 
diagnosed more nearly at the time they 
occur. 

• Knowledge of a language’s semantics 
can be used to generate and update code 
incrementally during editing. By incor- 


Much of the capacity 
of advanced hardware 
goes to waste because 
of inadequate 
software. Language- 
based editors using 
immediate 
computation can put 
this wasted capacity 
to work. 


porating code generation in a language- 
based editing environment, one attempts 
to provide programmers the ability to 
interleave program development with test¬ 
ing and debugging, avoiding lengthy 
recompilation delays. 


This article is adapted from the authors’ forthcoming 
book. The Synthesizer Generator. 


• A language’s syntax and semantics 
provide a basis for deriving additional 
meaningful relationships among program 
entities. Such knowledge, extracted and 
maintained automatically during program 
modification, can guide programmers or 
even constrain them. Having such infor¬ 
mation fosters comprehension; using it to 
define meaningful, high-level operations 
for restructuring programs promotes con¬ 
fidence and security. 

• Programs exist not in isolation, but in 
relation to supporting documents. 
Whether interleaved with the program or 
separate from it, designs and specifications 
become large and unwieldy; these auxiliary 
languages themselves need language-based 
tools. By combining knowledge of both 
the programming language and the design 
or specification language in a single pro¬ 
gramming tool, it is possible to furnish 
programmers with support for creating 
programs according to particular metho¬ 
dologies. 

This article illustrates each of these uses 
and describes a common formalism for 
incorporating such knowledge into 
language-based editors. 

Although we devote most of this article 
to the issues as they relate to programming 
environments, many of the ideas discussed 
have wider application. For example, 
many of the issues that arise in designing 
word processors, electronic spreadsheets, 
and systems for computer-aided design are 
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similar to the ones that arise when build¬ 
ing interactive language-based program¬ 
ming environments. In particular, the 
fundamental problem that confronts the 
builder of any interactive system is the 
problem of incremental change: The sys¬ 
tem must be designed to provide its serv¬ 
ices efficiently as the user makes a 
sequence of small changes. We need a 
general theory of incremental computing 
that addresses users’ needs for rapid 
response. The language-independent tech¬ 
niques being developed for incremental 
analysis in language-based environments 
are a step in the evolution of such a theory. 

Recent work on language-based envi¬ 
ronments has been influenced both by Lisp 
environments, which have long exploited 
the ability to process programs as data 
objects, and by some work in the 1970s in 
which program analysis, transformation, 
and translation facilities were incorpo¬ 
rated in language-specific editors for 
statically scoped, strongly typed lan¬ 
guages of the Algol family. For example, 
the Mentor project, 1 initiated in 1974, 
created a collection of special-purpose 
tools for processing Pascal abstract-syntax 
trees using a general-purpose tree- 
manipulation language. Around 1979, 
three systems—Gandalf, 2 Lispedit, 3 and 
the Cornell Program Synthesizer 4 — 
explored ways of integrating language- 
specific program editors with execution 
and debugging facilities. 

In subsequent years, research on inter¬ 
active, language-based program develop¬ 
ment environments has flourished; by 
now, there is a considerable body of pub¬ 
lished work on the subject, and it is an 
important topic at major conferences (see, 
for example, Henderson 5 ' 6 ). 

Our own work on programming envi¬ 
ronments has centered around two sys¬ 
tems. The first, the Cornell Program 
Synthesizer, was an interactive program¬ 
ming environment in which we combined 
a language-based editor for a small subset 
of PL/I with an incremental compiler and 
an interpreter. 

Our second system, the Synthesizer 
Generator, 7 is a generator of language- 
based editors. Just as a parser generator 
creates a parser from a grammar that 
specifies a language’s concrete syntax, the 
Synthesizer Generator creates a language- 
based editor from a specification of a lan¬ 
guage’s abstract syntax, context-sensitive 
relationships, display format, concrete 
input syntax, and transformation rules for 
restructuring programs. In developing the 
Synthesizer Generator, our goal was to 


facilitate the creation of programming 
environments similar in spirit to the Cor¬ 
nell Program Synthesizer, but with greatly 
enhanced capabilities (and for languages 
other than PL/I). 


Structure editing for 
syntactically correct 
programs 


A language-based program editor can 
apply knowledge of a language’s context- 
free syntax to ensure that programs are 
always syntactically well-formed. In such 
an editor, a program is represented by its 
derivation tree with respect to the under¬ 
lying context-free grammar. In this sec¬ 
tion, we review the benefits provided by 
structural editing operations that modify 
a program’s derivation-tree. 

A structure editor reinforces the view of 
a program as a hierarchical composition of 
computational structures. Programs are 
composed of templates , which provide 
predefined, formatted patterns for each of 
the constructs in the language, such as 
procedures and loops. Programs are 
created top-down by inserting new tem¬ 
plates at placeholders in the skeleton of 
previously entered templates. For exam¬ 
ple, in the template 

while <expr> do 
< statement > 

<expr> and < statement > are place¬ 
holders that identify where additional 
insertions may be made. 

During editing, the current selection 
(insertion point) indicated by the shaded 
region in the template above can only be 
moved from one template to another, or 
from one template to its constituents, not 
from character to character or from one 
line of text to another. 

Templates are inserted into the program 
by special commands, and the system 
checks whether the insertion makes sense. 
For example, if the currently selected ele¬ 
ment is < statement >, a menu command 
can be invoked to insert an if statement 
into the program, automatically indented 
in the body of the loop, as follows: 

while <expr> do 
if <expr> then 
< statement > 
else < statement > 

The menu of insertion commands need not 


provide the same choices in all contexts; 
restricting the choices offered to the inser¬ 
tions that are legal in the context of the cur¬ 
rent selection forbids the user from 
making inappropriate insertions. For 
example, because an if statement is not an 
appropriate derivation of an < expr> , the 
if-statement choice would not be offered 
in the menu when the loop condition is 
selected. 

With a structure editor, changes to a 
program are accomplished by removal and 
insertion of entire, well-formed program 
fragments. This highly disciplined mode of 
modification guarantees the structural 
integrity of the program at every step. 

Transformation operations in a struc¬ 
ture editor provide a mechanism for mak¬ 
ing controlled changes in a single step. 
Construct-to-construct transformation 
operations emphasize the abstract com¬ 
putational meaning of program units. 
Consider, for example, the following Pas¬ 
cal function that multiplies two integers by 
repeated addition: 


function multiply (a, b: integer): integer; 

var 

y, z: integer; 
begin 
y:= b 
z := 0; 

while y > 0 do 
begin 

y:=y- l; 

z:= z + a 

end; 

multiply: - z 

end 

In one operation, this fragment can be 
transformed into the equivalent imple¬ 
mentation: 

function multiply (a, b: integer): integer; 

var 

y, z: integer; 

begin 

y-=b\ 

Z : = 0; 
if y > 0 then 
repeat 
y t-y - 1; 
z := z + a 
until y <= 0; 
multiply : = z 
end 

A structure editor’s capabilities for eli- 
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sion allow a program’s display to be con¬ 
trolled according to its hierarchical 
structure. Users may be allowed manual 
control of the display, which permits them 
to hide unnecessary detail; alternatively, 
the system may automatically furnish a 
derived view of the program by selectively 
choosing to suppress certain parts of it. 
For example, one of the ways that might 
be chosen for displaying the first version 
of the multiply function is 


function multiply (a, b: integer): integer; 

begin 

y:= b; 

z : = 0; 

whiley > 0 do . . .; 
multiply : = z 

end 

Here the ellipses (. . .) indicate portions of 
the program whose display representation 
has been suppressed. 

Structure editing has a number of 
attractive properties. The integrated 
behavior of templates and the editor’s 
selection enforce the view of a program as 
a hierarchy of nested components. Place¬ 
holders in templates serve both as prompts 
and as syntactic constraints, by identify¬ 
ing places that can or must be refined and 
by restricting the range of choices to legiti¬ 
mate insertions. 

Templates eliminate mundane tasks of 
program development and let program¬ 
mers focus on the intellectually challeng¬ 
ing aspects of programming. Each 
template insertion is syntactically correct 
because template commands are valid only 
in appropriate contexts. Indentation is 
automatic, both when a template is intro¬ 
duced and when it is moved. Typographi¬ 
cal errors in structural units are 
impossible; the templates are predefined 
and immutable, so a modification cannot 
introduce errors. Thus, a program devel¬ 
oped with a structure editor is always well- 
formed, regardless of its completeness. 

Templates correspond to abstract com¬ 
putational units. Because they are inserted 
and manipulated as units, the process of 
programming begins and continues at a 
high level of abstraction. 

Do not get the idea that text editing and 
structure editing are incompatible. Struc¬ 
ture editors can be augmented with text 
editing facilities to create hybrid tree and 
text editors that have the advantages of 
both. While permitting both text editing 
and structure editing, a hybrid design can 



The dedicated 
processors of 
inexpensive personal 
computers are 
bringing about a shift 
to immediate 
computation. 


still preclude the creation of syntactically 
incorrect programs: All components 
inserted or modified textually (such as 
character-by-character) must be validated 
by the editor. A good strategy is to parse 
the text of the current selection (and only 
the text of the current selection) as soon as 
the programmer selects some other ele¬ 
ment of the program to work on. If the 
phrase contains an error, a message is 
printed and an indicator is positioned as 
close to the site of the error as possible. 

Using immediate 
computation to locate 
errors in programs 

Recently developed language-based edi¬ 
tors use an immediate-computation para¬ 
digm for program analysis, error 
reporting, and code generation. For exam¬ 
ple, to provide a user with feedback about 
existing program errors, the editor per¬ 
forms a static-semantic program analysis 
between editing modifications. The exploi¬ 
tation of spare machine cycles for such 
purposes is just one example of a general 
trend toward immediate computation, as 
we describe below. 

The path between the keypunch and the 
computer center was a familiar route to 
early computer users. Data prepared in 
advance were submitted as batches of 
input to be processed by the central 
machine. Although timesharing improved 
matters considerably—the interval 
between successive runs was reduced from 
hours to seconds and the trip to the com¬ 
puter center was eliminated—the essence 
of the batch mode, an alternation between 
data preparation and program execution, 
remained dominant. 

Recently, a new way of computing has 


begun to take hold; the dedicated proces¬ 
sors of inexpensive personal computers are 
bringing about a shift to immediate com¬ 
putation. In the immediate mode of com¬ 
putation, the editing function is embedded 
within the application program itself. 
Each modification to a datum is processed 
by the application and has essentially 
instantaneous effect. An important result 
is that a computation is always consistent 
with the current state of the data, thereby 
providing useful, immediate feedback to 
the user as the data are manipulated. Extra 
computation is required, of course, 
because the data pass through many inter¬ 
mediate states not arising in the batch 
mode. These extra steps are often accept¬ 
able, however, because immediate 
processing can use surplus processing 
capacity. (While the unused cycles of 
timeshared computers are at the disposal 
of others, the spare cycles of single-user 
computers go to waste.) Where applicable, 
the immediate-computation paradigm 
appears certain to take hold, especially as 
more powerful workstations appear. 

The trend towards immediate computa¬ 
tion is illustrated by developments in three 
areas: word processing, electronic spread¬ 
sheets, and language-based program 
editors. 

Recent word-processing systems use the 
immediate-computation paradigm. In the 
traditional batch-processing mode, an 
input file consisting of interleaved format¬ 
ting commands and textual data is pre¬ 
pared using a conventional text editor. The 
page layout is created only when this file 
is submitted to a document compiler. With 
the newer systems, formatting is per¬ 
formed interactively on a character-by- 
character basis, and at all times the screen 
resembles the final page layout. Such edi¬ 
tors are called WYSIWYG editors, 
because what you see is what you get. 

In Figure 1, the information displayed 
in (a) is used by the batch-oriented word¬ 
processing software of the Unix operating 
system. This typical input file consists of 
the interleaved text and commands to pro¬ 
duce the formatted document (b). With a 
WYSIWYG editor, the formatted page, 
such as the one in (b), is displayed on the 
screen at all times while the document is 
being modified. 

Electronic spreadsheets also follow the 
immediate-computation paradigm. In 
such a system a collection of related arith- 
matic calculations is displayed on the 
screen and a modification to the definition 
of any cell, either a single datum or a for¬ 
mula that expresses how the cell gets its 


November 1987 









I 


— 

_ 


_ 



Figure 1. A comparison of word processing by (a) a batch method and by (b) an 
immediate-processing method. 



Figure 2. An electronic spreadsheet is an example of a system that follows the 
immediate-computation paradigm. Each time a cell definition is revised, the screen 
is updated to reflect the consequences of the change. 


value as a function of other cells, causes all 
affected computations to be updated 
immediately. 

In the example in Figure 2, the Item, 
UnitPrice, and Quantity columns are user 
data; the Amount column and the Total 
are results of computations. A change in 
data would immediately be reflected in the 
computations. For example, if the Quan¬ 
tity of pens were changed, the Amount and 
Total would immediately be recomputed 
and displayed. Entering an improper 
value, such as a nonarithmetic Quantity, 
would result in an error message. 


Language-based program editors have 
been developed that use immediate com¬ 
putation to perform program analysis, to 
report errors, and to generate code while 
the program is being edited. With these 
systems, errors are detected early and the 
delay for compilation necessary with tra¬ 
ditional program-development tools is 
eliminated. As in a WYSIWYG text edi¬ 
tor, formatting according to program 
structure is immediate; as in an electronic 
spreadsheet, each modification to the pro¬ 
gram causes all affected analysis, error 
messages, and generated code to be 


immediately updated. 

In the Pascal program shown in Figure 
3a, the names size, index, list, and A are 
defined in terms of each other. In Figure 
3b, after redefinition of size from 10 to x, 
an error message appears because the 
name x has not been defined in the pro¬ 
gram. Changing x to -1 instantly removes 
this error, but introduces another at a dis¬ 
tant location, as illustrated in Figure 3c. 
This editor is, in effect, a spreadsheet for 
Pascal programs: The computations, 
updated after each editing transaction and 
displayed on the screen, concern correct¬ 
ness conditions for Pascal programs that 
can be determined by means of static 
inference. 

Although our own systems, the Cornell 
Program Synthesizer and the Synthesizer 
Generator, have promoted the immediate 
computation paradigm only for static pro¬ 
gram analysis, others have explored its 
application for program execution, as 
well. 8 


Using incremental code 
generation to support 
program testing 

To provide programmers with the abil¬ 
ity to combine program development with 
testing and debugging, program editors 
can support incremental translation as 
programs are created. A program can be 
translated into executable form during 
editing, and the code can be maintained as 
the program is modified. Having the pro¬ 
gram executable at all times allows the pro¬ 
grammer to interleave editing with 
preliminary program tests. 

For example, in programs developed 
using the Cornell Program Synthesizer, 
execution can be initiated at any time and 
begins immediately, without any delay for 
compilation. The programmer can inter¬ 
rupt an executing program, modify it, and, 
as long as the program still contains the 
structure associated with the interruption 
point, resume execution. It is even possi¬ 
ble to run incomplete programs: Execution 
suspends when a missing program element 
is encountered, but can resume after inser¬ 
tion of the required code. 

Incremental translation is advantageous 
both for generating intermediate code for 
interpretive systems like the Synthesizer 
and for generating machine code, as in 
Gandalf’s Incremental Programming 
Environment. 9 Another situation where it 
can be of great benefit is in a cross- 
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development environment. Incremental 
translation can serve as the basis for a 
cross-debugger where programs are devel¬ 
oped on a host machine and executed on 
a slave machine. 10 The editor on the host 
machine ships code over to the slave 
machine in small increments, thereby 
avoiding long delays for downloading a 
program that has been modified only 
slightly. 


Supporting program- 

development 

methodologies 

One of the responses to the “software 
crisis” has been to identify methodologies 
for program development. Immediate 
computation has the potential to play an 
important role in tools to support these 
methodologies. 

One school holds that a program should 
be developed in stages. During the first 
stage, the programmer should not be con¬ 
cerned with the efficiency with which a 
program solves the given problem. Rather, 
the programmer’s initial creation should 
provide an executable statement of a solu¬ 
tion for which it is easy to prove that the 
problem’s requirements are satisfied. In 
later stages, the program is rewritten 
through a sequence of correctness¬ 
preserving transformations until an effi¬ 
cient implementation is achieved. Support 
for this methodology can be provided by 
building in knowledge of language seman¬ 
tics and using it to determine if editing 
operations preserve correctness. 

A second school holds that a program 
should be developed hand-in-hand with a 
proof that the program satisfies its speci¬ 
fication. Support for this methodology 
can be provided in the form of a proof edi¬ 
tor that permits a programmer to create 
and modify program proofs. The editor 
provides the programmer with feedback 
about errors existing in a proof as it is 
developed, using knowledge (embedded 
within the editor) of the programming 
logic’s inference rules. 

A program and a proof of correctness 
can be presented as a proof outline. In a 
proof outline, the program is annotated 
with a precondition and a postcondition, 
and invariant assertions are provided for 
each loop. These annotations provide a 
formal specification of the program’s 
intended behavior. In a conventional 
program-verification system, a verifica¬ 


program p ; 
const 

size = 10; 

type 

index = 1 .. size-, 

list= array [index] of integer; 

var 

A: list, 


program p ; 
const 

size = x{ CONSTANT IDENTIFIER NOT DECLARED }; 

type 

index = 1 . . size; 

list= array [index] of integer; 

var 

A : list ; 


program p ; 
const 

size = -1; 

type 

index = 1 .. size { EMPTY RANGE NOT ALLOWED} ; 
list= array [index] of integer; 

var 


Figure 3. Three screen images taken from the authors’ Pascal program editor to 
illustrate its immediate error-analysis capability. In (b), after size is redefined from 
10 to x, an error message appears because the name x has not been defined in the 
program. Changing x to - 1 removes this error, but introduces a different one, as 
shown in (c). 


tion condition generator reduces the ques¬ 
tion of consistency between a program and 
a purported proof of correctness to that of 
the validity of formulae in the underlying 
theory. One drawback of conventional 
verification tools is that the formulae 
generated are divorced from the program 
context in which they arise. 

In contrast, it is possible to build a 
specialized proof editor that determines 
which proof obligations are not satisfied 
and displays information about the loca¬ 
tion of unsatisfied obligations. Such an 
editor uses the immediate computation 


paradigm: The editor keeps the user 
informed of errors and inconsistencies in 
a proof by reexamining the proof’s obli¬ 
gations after each modification to it. It 
then annotates the proof with warning 
messages to indicate locations where proof 
obligations are not satisfied. (See the side- 
bar “Using immediate computation in a 
program verifier” for an example.) 

The formulae produced in checking a 
proof outline’s proof obligations are 
ordinarily in an undecidable theory. One 
way to sidestep this problem is by having 
the user create and manipulate the 
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required proofs instead of having the sys¬ 
tem try to establish theorems automati¬ 
cally. By having the user create and 
manipulate proofs of verification condi¬ 
tions, we make the user responsible for 
proving theorems that an automatic the¬ 
orem prover might be incapable of 
proving. 


From a practical standpoint, this 
approach is unsatisfactory because the 
user is forced to prove theorems that auto¬ 
matic techniques are Capable of establish¬ 
ing. To provide an adequate tool, it is 
necessary to include automatic deductive 
capabilities in the editor so that the user 
does not have to supply complete (and 


repetitive) details of a proof. Two methods 
are possible: The editor can be extended 
with decision procedures (algorithms for 
deciding simple theories) and proof tactics 
(procedures that make an attempt to con¬ 
struct a proof tree but may leave some 
nodes unexpanded for the user to fill in 
later). 


Using immediate computation in a program verifier 


To illustrate how the immediate computation paradigm 
could be applied in a program-verification editor, we present 
an example editing session where the goal is to create a pro¬ 
gram for computing the product of two integers using 
repeated addition. More precisely, the goal is to create a frag¬ 
ment of code such that, whenever variable b is greater than or 
equal to 0, the variable z is assigned the product of a and b. 
Thus, the pre- and post-conditions of the desired fragment are 
b> 0 and z = a*b, respectively. 

Let us suppose that our initial attempt to create the mul¬ 
tiplication program resulted in the following proof outline: 
{b>0} 

y: = b 

z : = 0 

while y>0 invariant y>-1 & a*y + z = a*b do 
y : = y-1 
z: = z + a 

od { EXIT OBLIGATION NOT ESTABLISHED } 

{z = a*t>} 

The comment “{ EXIT OBLIGATION NOT ESTABLISHED }” is a 
warning supplied by the editor, indicating the presence of an 
unfulfilled proof obligation. 

Proof obligations concern disjoint sections of straight-line 
code. For the example shown above there are three of them: 
{t>>0} 
y: = b 
z : = 0 

{y>-1 &a*y + * = a*b} 

{y>0&y>-1 &a"y + z = a*b} 
y := y—1 
z: = z + a 

{y>-1 & a*y + z = a'b} 

{~(y>0) &y>-1 &a*y + z = a*b} 

{z = a*b} 

We will refer to them as the initialization obligation, the 
invariance obligation, and the exit obligation, respectively. 

The initialization obligation expresses the requirement that 
the (claimed) invariant of the loop be established when the 
loop is entered. The role of the invariance obligation is to 
show that the predicate given as the loop-invariant actually is 
an invariant for the loop; that is, we must show that, starting 
in a state that satisfies the conjunction of the condition and 
the invariant, the loop-body reestablishes the invariant on 
each iteration. The role of the exit obligation is to show that 
the conjunction of the invariant and the negation of the loop- 
condition establishes the post-condition of the loop. 


For the proof outline shown above, the exit obligation fails 
to be satisfied. 

Now suppose that, in an attempt to correct the proof out¬ 
line, the first clause of the invariant assertion is changed to 
y> 0: 

{b>0} 
y: = b 
z :=0 

while y>0 invariant y>0 & a*y + z = a*b do 

{ INVARIANCE OBLIGATION NOT ESTABLISHED } 

y: = y-1 

z:=z+a 

od 

{z = a*b} 

With the change, the message about the failure to establish 
the exit condition disappears. However, the loop now carries a 
new message, “{ INVARIANCE OBLIGATION NOT ESTAB¬ 
LISHED },” indicating that the loop-body fails to reestablish 
the invariant on each iteration of the loop. 

The modification of the proof outline changed the proof 
obligations from the previous ones to the following ones: 

{b>0} 
y:=b 
z :=0 

{y>0&a*y + z = a*b} 

{y>0&y>0&a*y + z = a‘b} 

y;=y-1 

z:=z + a 

{y>0&a*y + 'z = a*b} 

{~(y>0 & y>0&a*y + z = a*b} 

{z = a*b} 

In operational terms, the error in the program is that the 
loop-condition permits the loop to execute one too many 
times. The problem can be corrected by changing the loop- 
condition to be y>0. With this change, the program’s state¬ 
ments are now consistent with the assertions that annotate it 
and all warning messages in the program disappear: 

{b>0} 
y : = b 
z :=0 

while y>0 invariant y>0 & a*y + z = a*b do 

y ;=y-i 

z : = z + a 

od 

{z = a*b} 
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The need for 
incremental algorithms 

Widespread adoption of the immediate 
mode of computation by new application 
software is making the study of incremen¬ 
tal algorithms very important. 

Suppose a program computes the func¬ 
tion/on the user’s data x, where both x 
and f(x) may be either scalars or vectors. 
If the program follows the immediate- 
computation paradigm, then the moment 
the user changes the data from x to x' the 
program must compute/(x') and discard 
f(x). Of course, fix ') could be calculated 
from scratch, but this would usually be too 
slow to provide adequate response. What 
is needed is an algorithm that reuses old 
information to avoid as much recomputa¬ 
tion as possible. Because the increment 
from x to x ' is often small, the increment 
from/(x) to f{x') is frequently also small. 
An algorithm that uses information in the 
old value fix) to compute the new value 
fix’) is called incremental. 

The advantage of an incremental algo¬ 
rithm is illustrated by what happens on the 
screen when a document is corrected on a 
word processor with a WYSIWYG editor. 
In the WYSIWYG editor, x is the internal 
data structure used to represent the docu¬ 
ment, fix) is the initial formatted docu¬ 
ment, and/(x') is the corrected version. 
Suppose a small change, such as inserting 
a single character in the middle of a docu¬ 
ment, is made. Possibly a major change in 
the format would result, but this is unlikely 
for two reasons: independence and quies¬ 
cence. The format of the text that precedes 
the inserted character in no way depends 
on that character, and is thus unaffected 
by the change. This is independence. In the 
text that follows the inserted character, the 
format usually changes only locally. Even 
if the inserted character causes some words 
to snake around to succeeding lines, the 
propagation of changes will die out if there 
is enough space on the last line of the para¬ 
graph to prevent the addition of an extra 
line; the remainder of the document will be 
unaffected. This is quiescence. An 
incremental formatting algorithm can 
exploit independence and quiescence so 
that the minimal amount of reanalysis 
takes place. 

We can distinguish between two 
approaches to incremental algorithms: 
selective recomputation and differential 
evaluation. In selective recomputation, 
values independent of changed data are 
never recomputed. Such values may be 


either intermediate results of scalar com¬ 
putations or individual components of 
vector calculations. Values dependent on 
changed data are recomputed, but after 
each partial result is obtained, the old and 
new values of that part are compared; 
when changes die out, no further recom¬ 
putations take place. In differential evalu¬ 
ation, rather than recomputing/(x') in 
terms of the new data x', the old value fix) 
is updated by some difference A/ com¬ 
puted as a function of x, x', and fix). 

The spreadsheet example of Figure 2 can 
be used to illustrate the two approaches. 

To illustrate selective recomputation, let 
us suppose that UnitPrice pen and Quan¬ 
tity are changed to $1.00 and 1, respec¬ 
tively: Dependency information can be 
used to determine that Amount pad need 
not be recomputed, since it cannot change. 
Although Amount pen must be recom¬ 
puted, it turns out to be unchanged, there¬ 
fore Total need not be recomputed. 

To illustrate differential evaluation, let 
us suppose that UnitPricepen is changed to 
$1.00 and Quantity pe „ is left unchanged. 
Then the differences 
AUnitPricepen = $0.50 
AAmountpe„ = 

AUnitPrice pen x Quantity pen = $1.00 
ATotal = AAmountpen = $1.00 

can be computed and used for updating 
Amountpen and Total. Note that with 
differential evaluation, even if there are 
hundreds of lines of data, Total can be 
updated with a single addition. 

Sophisticated incremental algorithms 
are not always needed because exhaustive 
recomputation can be fast enough for 
small problems. But for language-based 
tools to have a major effect on the produc¬ 
tivity of software production, they must 
apply to large software systems. The larger 
the application, the more crucial is the 
need for incremental methods. 

Adapting specifications 
for immediate 
computation 

In traditional batch-mode systems, such 
as word processors and compilers, data 
items from the input file are processed 
sequentially. In contrast, in systems that 
follow the immediate-computation para¬ 
digm, data items are inserted and deleted 
in arbitrary order, with the system’s 
response reflecting the current state of the 
user’s data. 


The absence of any predetermined order 
for processing data, together with the 
desire to employ incremental algorithms 
for this task, creates additional complex¬ 
ity in the design of systems that perform 
immediate computation. The actions of 
batch-mode systems are specified imper¬ 
atively, that is, they are implemented with 
an imperative programming language in 
which a computation follows an ordered 
sequence of state transitions. Although 
imperative specifications have also been 
employed in immediate-mode systems, 
several systems have made use of an alter¬ 
native approach: declarative specifica¬ 
tions, defined as collections of 
simultaneous equations whose solution is 
the desired computation. 

The salient features of declarative spec¬ 
ifications are that 

• the order of solution is left unspeci¬ 
fied, and 

• the dependence of variables on data 
and on one another is implicit in the 
equations. Whenever the data 
change, an incremental algorithm can 
be used to re-solve the equations, 
retaining as much of the previous 
solution as possible. 

For example, the “program” executing 
the spreadsheet of Figure 2 is merely the set 
of equations 

UnitPrice pen = $0.50 
Quantity pen = 2 
UnitPrice pad = $0.75 
Quantity pad = 3 

Amountp Cn = UnitPrice pen x Quantity pen 
Amountp ad = UnitPrice pad x Quantity pad 
Total = Amountpen + Amount pad 

Changing data is, in effect, changing some 
of the equations, after which those equa¬ 
tions and perhaps other equations must be 
re-solved. 

The attribute grammar formalism 
adopted by the Synthesizer group for 
defining immediate error-analysis in pro¬ 
gram editors is such a declarative specifi¬ 
cation language. For each program that a 
user may create, the attribute grammar 
defines a corresponding set of simultane¬ 
ous equations whose solution expresses the 
deductions of the editor about errors in the 
program. Each unknown variable in these 
equations represents a deduction relevant 
at a particular point in the program. Dur¬ 
ing editing, each modification to the pro¬ 
gram causes a related change to the set of 
equations and their solution. Error mes- 
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Attribute grammars and the attribute-grammar model of editing 


As illustrated by the examples shown in Figure 3b and 3c, a 
modification to one part of a program may introduce an error 
in some other part of the program and simultaneously correct 
an error in a third part of the program. Detecting violations of 
language constraints may thus require a widespread analysis 
of the program. Here we give a brief introduction to the analy¬ 
sis method employed in the Synthesizer Generator. 

The Synthesizer Generator is based on the concept of an 
attribute grammar ,' which provides a powerful mechanism for 
specifying how widely separated parts of a program are con¬ 
strained in the context provided by the rest of the program. An 
attribute grammar is a context-free grammar extended by 
attaching attributes to the nonterminal symbols of the gram¬ 
mar, and by supplying attribute equations to define attribute 
values. In every production p:X 0 —X, ... X k , each X, denotes an 
occurrence of a grammar symbol. Associated with each non¬ 
terminal occurrence is a set of attribute occurrences cor¬ 
responding to the nonterminal’s attributes. 

Each production has a set of attribute equations; each 
equation defines one of the production’s attribute occurences 
as the value of an attribute-definition function applied to other 
attribute occurrences in the production. The attributes of a 
nonterminal are divided into two disjoint classes: synthesized 
attributes and inherited attributes. Each attribute equation 
defines a value for a synthesized attribute occurrence of the 
left-hand side nonterminal or an inherited attribute occur¬ 
rence of a right-hand side nonterminal. By convention, we deal 
only with attribute grammars that are noncircular— that is, 
grammars for which none of the derivation trees have circu¬ 
larly defined attributes. 

These concepts are illustrated by the attribute grammar 
given in the figure at right. (For brevity, the figure does not 
show the productions that can be derived from the nontermi¬ 
nals identifier and exp. In the equations in the figure, we have 
used conventionally accepted notation to express operations 
on sets, as the operator for selecting an attribute of a non¬ 
terminal, and subscripts to distinguish among multiple occur¬ 
rences of the same nonterminal.) 

The figure defines a scheme to compute the set of declared 
names via the attributes id and env attached to certain nonter¬ 
minals of the grammar. Id is a synthesized attribute of the 
nonterminal identifier; its value is an identifier name. Env is a 
synthesized attribute of decIList and an inherited attribute of 
stmtList and stmt; its value is a set of identifier names. 

Attribute equations define how the values of attributes are 
related to the values of other attributes. Rules 2 and 3 of the 
figure describe how a symbol table is generated from the 
declarations of a program. Rule 1 causes the symbol table to 
be passed from the declarations to the statements of the pro¬ 
gram. Rules 4 through 9 describe how the table is propagated 
to the individual statements of the program. 

A derivation tree node that is an instance of symbol X has 
an associated set of attribute instances corresponding to the 
attributes of X. An attributed tree is a derivation tree together 
with an assignment of either a value or the special token null 
to each attribute instance of the tree. To analyze a program 
according to its attribute-grammar specification, first con¬ 
struct its derivation tree with an assignment of null to each 
attribute instance, then evaluate as many attribute instances 
as possible, using the appropriate attribute equation as an 
assignment statement. The latter process is termed attribute 
evaluation. 


Functional dependencies among attribute instances in a 
tree T can be represented by a directed graph, called a depen¬ 
dency graph. A grammar is noncircular when the dependency 
graphs of all of the grammar’s derivation trees are acyclic. 

Example. The diagram shown in the figure on the facing 
page depicts the derivation tree and dependency graph of the 
following program fragment: 

program p 
var 

declare q 
declare r 
begin 

stmt 

stmt 

stmt 

end 

The nonterminals of the derivation tree are connected by 
dashed lines; the dependency graph consists of the instances 


(1) program-program identifier var decIList begin stmtList end 

stmtListenv = deciList.env 

(2) decIList—declare identifier 

decIListenv = { identifier.id } 

(3) decIList—declare identifier decIList 

decIListi.env- [identifier.id] U deciListg.env 

(4) stmtList—stmt 

stmt.env= stmtUst.env 

(5) stmtList-stmt stmtList 

stmt.env= stmtList-/.env 
stmtList^env = stmtList pen v 

(6) stmt—identifier := exp 

exp.env = stmt.env 

(7) stmt—if exp then stmt else stmt 

exp.env= stmtpenv 
stmt 2 ~env= stmtpenv 
stmtg.env= stmtpenv 

(8) stmt—while exp do stmt 

exp.env= stmtpenv 
stmtpenv = stmtpenv 

(9) stmt-begin stmtList end 

stmtUst.env = stmt.env 


Propagation of symbol table information. 
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of the attributes env and id linked by their functional depen¬ 
dencies, shown as solid arrows. (The solid arrows emanating 
from the tree’s identifier leaves indicate dependencies on tree 
components; strictly speaking, they are not part of the depen¬ 
dency graph.) 

When an editor designer creates an editor with the Syn¬ 
thesizer Generator, part of the editor specification consists of 
attribute equations that express context-sensitive language 
constraints or computations of derived information. As a pro¬ 
gram is developed with the generated editor, it is represented 
as a derivation tree consistently attributed in accordance with 
the grammar’s equations. When a program is modified by 
replacing one of its subtrees, some of the attributes may no 
longer have consistent values. 

Incremental analysis is performed by updating attribute 
values throughout the tree in response to modifications. By 
following the dependency relationships between attributes as 
defined in the editor specification, it is possible to reestablish 
consistent values throughout the tree. 

Fundamental to this approach is the idea of an incremental 
attribute evaluator, an algorithm to produce a consistent, fully 
attributed tree after each restructuring operation. Of course, 
any nonincremental attribute evaluator could be applied to 
completely reevaluate the tree, but the goal is to minimize 


work by confining the scope of reevaluation required. 

After each modification to a program tree, only a subset of 
attributes, denoted by AFFECTED, requires new values. It 
should be understood that when updating begins, it is not 
known which attributes are members of AFFECTED; 
AFFECTED is determined as a result of the updating process 
itself. Reps 2 described algorithms that identify attributes in 
AFFECTED and recompute their values. Some of these 
algorithms have costs proportional to the size of AFFECTED. 
This means that they are asymptotically optimal in time, 
because, by definition, the work needed to update the tree can 
be no less than |AFFECTED|. 
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sages that appear and disappear on the 
screen (as in Figure 3) are merely the values 
of textual variables that change from time 
to time as the equations are re-solved. (See 
the sidebar “Attribute grammars and the 
attribute-grammar model of editing” for 
additional details.) 

For example, suppose the + operator of 
the language denotes addition of integer 
operands (and is not overloaded for other 
kinds of operands). Then the expression 
1 + 5 would be associated with the follow¬ 
ing set of equations: 

typeOf+ = integer 
typeO/ief,operand = integer 
typeou ghtoperand = integer 
error + = 

if ^peQ/i ef ,operand= integer 

and fypeO/rightoperand = integer 

then 

else “TYPE MISMATCH” fi 

In the solution of these equations, the vari¬ 
able error + has the value (the empty 


string). If, however, the expression were 
changed to 1 + “a string”, then the equa¬ 
tions would be 

typeOf + = integer 
typeOf Ml0pcrmi = integer 
t^peO/rightoperand = string 
error+ 

it OpeQ/ieftoperand = integer 

and fypeO/righ,Operand = integer 

then 

else “TYPE MISMATCH” fi 

In the solution of the latter equations, the 
variable error + has the value “TYPE 
MISMATCH”. 

Attribute grammars have several desir¬ 
able qualities as a notation for specifying 
language-based editors. A language is 
specified in a modular fashion by an attrib¬ 
ute grammar: syntax is defined by a 
context-free grammar and attribution is 
defined in an equally modular fashion, 
because the arguments to each attribute 
equation are local to one production. 


Propagation of attribute values through 
the derivation tree is not specified 
explicitly in an attribute grammar; rather, 
it is implicitly defined by the equations of 
the grammar and the form of the tree. 

The benefit of using attribute grammars 
to handle the problem of incremental 
change in language-based editors is that 
the repropagation of consistent attribute 
values after modification of a program is 
implicit in the formalism. Thus, there is no 
need for the notions of “undoing a seman¬ 
tic action” or “reversing the side-effects 
of a previous analysis,” which would 
otherwise be necessary. When a program 
is modified, consistent relationships 
among the attributes can be reestablished 
automatically by incrementally re-solving 
the system of attribute equations. Conse¬ 
quently, when an editor is specified with 
an attribute grammar, the method for 
achieving a consistent state after an edit¬ 
ing modification is not part of the specifi¬ 
cation. 

Apart from its use to specify name anal¬ 
ysis and type checking, the attribute- 


The Synthesizer Generator 


The Synthesizer Generator creates a language-specific edi¬ 
tor from an input specification that defines a language’s 
abstract syntax, context-sensitive relationships, display for¬ 
mat, concrete input syntax, and transformation rules for 
restructuring programs. From this specification, the Genera¬ 
tor creates a display editor for manipulating objects according 
to these rules. 

The treatment of language syntax by the Generator has par¬ 
ticular importance. The editor designer’s specification of the 
language’s syntax addresses not only context-free syntax but 
also such context-sensitive conditions as type correctness. As 
the user creates and modifies programs, the generated editor 
incrementally checks for violations of context conditions that 
have been specified. 

Context conditions are expressed by introducing certain 
attributes whose attribute equations indicate whether or not a 
constraint is satisfied. The manner in which programs are 
annotated with information about violations of context condi¬ 
tions is expressed by the editor’s unparsing specification, 
which determines how programs are displayed on the screen. 
Attributes used in the unparsing specification cause the pro¬ 
gram display to be annotated with values of attribute 
instances. In particular, the attributes that indicate satisfac¬ 
tion or violation of context-dependent constraints can be used 
to annotate the display to indicate the presence or absence of 
errors. If an editing operation modifies a program in such a 
way that formerly satisfied constraints are now violated (alter¬ 
natively, formerly violated constraints are now satisfied), the 
attributes that indicate satisfaction of constraints will receive 
new values. The changed image of these attributes on the 
screen provides the user with feedback about new errors intro¬ 
duced and old errors corrected. 


Editor specifications are written in the Synthesizer Specifi¬ 
cation Language (SSL), which is built around the concepts of 
an attribute grammar and a type-definition facility, although 
certain features are tailored to the application domain of 
language-based editors. In SSL, an attribute's type can either 
be one of the built-in, primitive types, or it can be a user- 
defined, composite type. In an editor specification, one uses 
precisely the same sort of rules to define new attribute types 
as one uses to define abstract syntax. This design, in which 
the abstract-syntax tree being edited and the attributes 
attached to it are all elements of a single domain of values, 
permits writing attribution schemes whose computations cre¬ 
ate new syntactic objects. 

The Synthesizer Generator has been used to produce proto¬ 
type editors for a wide variety of applications, including WYSI¬ 
WYG editors for both text and mathematical formulas, editors 
that verify the correctness of proofs in several varieties of 
mathematical logic, and program editors for several different 
programming languages (including an editor for full Pascal 
with complete static-semantic checking). 

The Synthesizer Generator is written in C and runs under 
Berkeley Unix. Editors can be generated for the X Window Sys¬ 
tem and for SunView, as well as for video display terminals. 
Editors generated for X or SunView support multiple overlap¬ 
ping windows and the use of the mouse to make selections in 
edited objects, to select commands and transformations from 
menus, and to scroll, resize, and iconify windows. 

The Synthesizer Generator is available from the Department 
of Computer Science at Cornell University and has been 
licensed to about 150 sites. The release consists of both 
source and object code, plus a reference manual and a variety 
of demonstration editors. 
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grammar formalism provides a basis for 
specifying a large variety of other compu¬ 
tations on tree-structured data, including 
type inference (as distinct from type check¬ 
ing), codegeneration, proof checking, and 
text formatting (including filling and 
justification, as well as equation for¬ 
matting). 

The chief drawback to the use of attrib¬ 
ute grammars for creating program editors 
that perform immediate computation is 
the question of whether certain efficiency 
problems prevent the approach from scal¬ 
ing up. The problem is that attribute gram¬ 
mars have strictly local dependencies 
among attribute values, and, at least con¬ 
ceptually, attributed trees have a large 
number of intermediate attribute values 
that must be updated. In contrast, imper¬ 
ative methods for implementing checks on 
a language’s context conditions can, by 
using auxiliary data structures to record 
nonlocal dependencies in the tree, skip 
over arbitrarily large sections of the tree 
that attribute-updating algorithms visit 
node by node. 

For example, suppose we want to 
enforce the constraint that the declarations 
and uses of identifiers in a program be con¬ 
sistent. An imperative approach can 
implement this constraint with a symbol 
table for each block, in which the entry for 
an identifier / points to a chain of all uses 
of / in that block. When a declaration is 
deleted or inserted, the use chains are 
employed to immediately access uses of 
variables formerly declared. With the 
attribute-grammar approach, when a 
declaration is deleted or inserted the 
incremental attribute evaluator traverses 
the entire declaration. 

Some recent work on attribute- 
grammar extensions (including Demers et 
al., u Johnson and Fischer, 12 Reps et al., 13 
and Hoover 14 ) has been directed towards 
abandoning the restriction to purely local 
attribute dependencies. This matter 
remains a topic for additional research. 

Generating language- 
based programming 
environments 

Many language-based environments are 
under development world-wide. With 
some exceptions—Mentor, Gandalf, and 
the Synthesizer Generator (see the sidebar 
“The Synthesizer Generator”)—most are 
hand-tailored for the particular applica¬ 
tion, be it a programming language, design 


language, specification language, system 
modeling language, theorem prover, etc. 

All language-based environments share 
many language-independent features. 
These include maintaining an abstract rep¬ 
resentation of the object being edited and 
a collection of derived information as the 
object changes. For example, a program 
editor must maintain the correct type 
assignments for each subexpression as 
variable declarations change; a proof edi¬ 
tor must maintain its verification that a 
given proof proves a given proposition as 
both are modified; a WYSIWYG editor 
must maintain the spacing values that 


affect right-justification of text, and so 
forth. While these examples are domain- 
specific, the notion of incrementally main¬ 
taining a collection of derived informa¬ 
tion, and many of the techniques for doing 
so efficiently, are language-independent. 

In addition to these tasks, every editing 
environment must provide many mun¬ 
dane, language-independent services, such 
as commands for navigating through the 
object and allowing the user to save and 
restore the object using the file system. A 
user interface must be developed, with 
bindings of key sequences to generic com¬ 
mands implemented in the environment, 
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such as selection of subobjects, as well as 
application-specific commands. Buffers 
for edited objects must be created, main¬ 
tained, and interfaced to the windowing 
systems that the environment is expected 
to support. Editing operations (deletion, 
in-place text editing, etc.) must not only 
affect the internal representation of the 
object, but the display of the object must 
be incrementally updated. In general, the 
size of the language-independent code 
dominates that of the language-specific 
code. 

When people build language-based edi¬ 
tors in an ad hoc manner, there is a lament¬ 
able duplication of effort and misspent 
expertise as specialists in many different 
application areas struggle with the same 
details of windowing systems, parsing of 
input commands, and the like. The result¬ 
ing systems also suffer from ad hoc solu¬ 
tions to problems for which systematic 
solutions have been found, for example, 
incremental change propagation of de¬ 
rived information. 

In contrast, editor-generating systems 
facilitate the creation of editing systems 
individually tailored for different lan¬ 
guages. Although each different editor 
produced with an editor-generating system 
has different characteristics, all share the 
common user-interface of the generator’s 
editing kernel. 


T oday’s powerful stand-alone 
computers provide virtually free 
processing, but for us to make full 
use of their potential, the impressive 
advances in hardware must be accompa¬ 
nied by the development of appropriate, 
innovative software. Much of the capac¬ 
ity of hardware, which can perform mil¬ 
lions of operations between every pair of 
consecutive keystrokes, is currently going 
to waste. Language-based editors offer a 
way to put this capacity to work. 
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What Can Software Engineers 
Learn from Artificial 
Intelligence? 

Walter F. Tichy 
University of Karlsruhe 


The problem is not retraining 
software engineers in Al; they learn 
quickly. The problem is convincing 
them that they need retraining. 

—Mark Fox 


T his article is a critical, in-depth 
assessment of artificial intelli¬ 
gence programming tools by a 
non-AI scientist. It is based on my inten¬ 
sive personal involvement with the follow¬ 
ing programming tools: frame-based 
representation languages, Lisp program¬ 
ming environments, natural-language 
parsers, production systems, and Prolog. 
My most significant initial insight result¬ 
ing from this experience is that frame- 
based representation facilities with 
inheritance and a sophisticated Lisp sys¬ 
tem synthesize a language level noticeably 
higher than that of languages in the Algol 
tradition, such as Ada, Modula, C, or Pas¬ 
cal. The higher language level makes pro¬ 
gramming easier and allows programmers 
to see further. It makes it possible to 
envisage and build sophisticated systems 
that might be rejected as too advanced or 
too expensive to construct in traditional 
environments. 

Natural-language parsers are fascinat¬ 
ing because they complement current 


Frame-based 
representation 
languages, 
sophisticated Lisp 
programming 
environments, and 
natural-language 
parsers not only 
increase programmers’ 
productivity but also 
extend their creative 
horizons for building 
novel software 
systems. 

interface technology. A natural-language 
parser accepts typed English sentences and 
translates them into an internal represen¬ 
tation to be interpreted by an application 
program. The technology of such parsers 


has now matured to the point that they can 
be used in practice. Constructing gram¬ 
mars for such parsers, however, is still 
highly labor intensive. 

I am less enthusiastic about Prolog and 
production systems such as OPS5. Prolog 
resembles early Lisp dialects: an elegant 
programming language that has yet to 
prove itself. Prolog programs can be sur¬ 
prisingly simple and lucid for problems 
that are best solved with depth-first search. 
However, for other solution strategies, 
Prolog programs are rarely clearer than 
equivalent programs in Common Lisp. 
Pure production systems such as OPS5 
have a narrow application domain and are 
a step backward in terms of control struc¬ 
ture. Finally, a drawback of all AI lan¬ 
guages mentioned so far is the lack of 
adequate constructs for parallel and dis¬ 
tributed processing. 

Since the above tools have different 
strengths and weaknesses, tool integration 
is important. This means that one should 
be able to combine any and all of these 
tools in a single program. For example, it 
should be possible to represent knowledge 
about a problem domain with frames, 
access this information from Prolog, 
switch to Lisp or a production system 
where appropriate, and interact with the 
user from any of those languages through 
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a wide-spectrum user interface that 
includes raster graphics and natural lan¬ 
guage. Integration makes it possible to 
choose the right tool for the problem at 
hand. 

A final but important ingredient is the 
AI culture in which the above tools 
evolved. In an almost tangible way, this 
culture fosters smart systems, where smart 
means more sophisticated, more auto¬ 
mated, and more user-oriented than com¬ 
parable systems. Programmers trained in 
AI actively and deliberately search for 
ways to make their systems behave in 
clever ways. A most serious insult in this 
culture is to be accused of having written 
a dumb program. 

Lest it be lost in the current excitement 
surrounding artificial intelligence, I hasten 
to point out that even the best AI tools are 
not magical. They do not provide answers 
to the fundamental question of computer 
science: What can be automated?' The 
creative task of identifying and specifying 
the functions that can be performed by 
machine is still left to the human being. 
However, I found that AI tools stimulate 
the necessary creativity and that once an 
automatable function has been identified, 
it can be implemented and refined quickly. 

Although AI tools are excellent for pro¬ 
totyping, they are not limited to this devel¬ 
opment paradigm. Indeed, the sign of a 
good prototyping tool is that it will even¬ 
tually find its way into production. At least 
frame languages and Lisp programming 
environments are now used in production 
daily. 

The following sections provide a 
detailed analysis of the AI tools men¬ 
tioned. The emphasis is on depth rather 
than breadth, so instead of providing a 
comprehensive survey, I discuss only one 
representative from each class of tools. 
Each representative selected is state-of- 
the-art, yet pure enough to permit a clear 
description of its salient features and 
established enough to be in use among 
several groups beyond its original inven¬ 
tors. Despite this apparent bias, the con¬ 
clusions drawn about a particular tool 
apply to all members of its class. 

Frame-based 

representation 

languages 

Frame-based representation languages, 
or frame languages for short, are used to 
build and process semantic nets. Seman¬ 


tic nets, originally designed to represent 
the meanings of English words, have sub¬ 
sequently become popular for represent¬ 
ing concepts of a widely varying sort. They 
have their roots in the hypothesis that 
human knowledge is structured as an 
associative network of concepts. 

Quillian is generally acknowledged as 
the inventor of semantic nets. 2 In his 1966 
PhD thesis, Quillian proposed an associa- 
tional network model for representing the 
“objective” meanings of words. He 
modeled individual words as nodes and 
connected each node to others by various 
types of associative links. A node together 
with the nodes reachable from it made up 
the complete definition of a word. Quillian 
also introduced the idea of inheriting 
attributes along a special link for con¬ 
structing taxonomic hierarchies. Today 
this link is often called the is-a relation (it 
is also known variously as is, superclass, 
ako, and subset) and can be found in all 
frame languages. 

Since their introduction by Quillian, 
semantic network models evolved rapidly 
and were implemented in languages such 
as KL-One, NETL, FRL, Units, KRL, 
KEE, and SRL. Terminology has changed 
somewhat: Nodes are now called frames, 
and links are called relations. A frame is 
a named collection of information, simi¬ 
lar to a record in more traditional lan¬ 
guages. The record fields are called slots. 
Slots have names and contain values. The 
values can be, for instance, symbols, lists, 
names of functions, sets of production 
rules, or links to other frames. Operations 
are available for creating and deleting 
frames and for reading and writing the 
values in the slots. 

Relations connect pairs of frames. 
Unlike relational databases, which oper¬ 
ate on relation tables, frame languages 
present relations as pointers: Given a 
frame, one can find related frames by fol¬ 
lowing the pointers stored in its slots. 

Inheritance differentiates frame lan¬ 
guages from those that provide relation 
tables or records and pointers. Inheritance 
supplies a frame with implicit slots and 
values that are obtained (inherited) from 
other frames. Relations are the paths over 
which these inherited items travel. Simple 
inheritance means that each frame can 
inherit via at most one path; multiple 
inheritance is the generalization to multi¬ 
ple paths. Multiple inheritance is impor¬ 
tant for modeling the combination of 
orthogonal concepts. It may also cause 
ambiguities. For example, when attempt¬ 
ing to read the value of a slot of some 


frame, one may have to choose among the 
values of several inheritable slots with the 
same name. A search rule resolves this 
ambiguity, or, if a list of all inheritable 
items is desired, it determines the order of 
the list. A simple search rule (already pre¬ 
sent in Quillian’s work) is breadth-first 
search across all relations traversable from 
a given frame, where siblings of a frame 
are visited in order of creation. Breadth- 
first search also implements the override 
rule—that is, when a slot is explicitly pre¬ 
sent in a frame, then slots with the same 
name that could be inherited are invisible. 

The modeling power of frame languages 
is significantly greater than that of more 
traditional programming languages. 
Frames by themselves (without relations 
and inheritance) can represent abstract 
data types as well as instances of these 
types. The instance frames should be 
linked via the instance relation to their type 
frames. This linkage allows slots and 
default values to be inherited from the type 
frames and also to retrieve and process all 
instances of a given type at runtime. By 
adding a second relation, the is-a relation, 
and using it to organize type frames in a 
classification hierarchy, frame languages 
can support object-oriented program¬ 
ming. In this style of programming, types 
inherit slots and values (including opera¬ 
tions) from their supertypes and pass them 
on to their subtypes and instances. 

Relations by themselves (with 
inheritance disabled) can be thought of as 
pointers among frames, so frame lan¬ 
guages can represent any kind of linked 
data structure. In some frame languages 
inverse relations are kept up to date auto¬ 
matically. Operationally this means that 
links can be viewed as two-way pointers. 
Two-way pointers eliminate the problem 
of the dangling reference because when¬ 
ever a frame is deleted, all pointers to that 
frame can be removed automatically by 
tracking the inverses emanating from the 
deleted frame. 

While many frame languages provide 
only two relations (variants of is-a and 
instance), advanced languages allow the 
user to define new relations. Commonly 
needed relations express connections such 
as aggregation, elaboration, abstraction, 
revision, default, precedence, similarity, 
and causality. Inheritance coupled with 
these relations simplifies processing the 
network because inheritance eliminates 
redundant representation yet gathers rele¬ 
vant information automatically. The user 
gains further expressiveness by building 
subclasses of relations. For example, it 
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Figure 1. An inheritance network for vehicles. 


might be worthwhile to differentiate 
several kinds of aggregation and causality 
links in an application. Classifying rela¬ 
tions has similar structuring benefits as 
classifying types. 

Object-oriented programming. Object- 
oriented programming has become a term 
for programming with inheritable, 
abstract data types. It is often assumed 
that an important aspect of object- 
oriented programming is the notion of 
sending a message to an object—that is, to 
a frame—in order to invoke an operation 
associated with that object. While the 
association of objects with operations is 
important, message sending is not. Mes¬ 
sage sending is merely a convenient nota¬ 
tion for invoking an operation associated 


with a frame. In that light, object-oriented 
programming languages would hardly dif¬ 
fer from programming languages with 
abstract data types. The essential charac¬ 
teristic is the ability to organize abstract 
data types into a hierarchy of sub- and 
supertypes and to inherit slots and opera¬ 
tions from a type to its subtypes. Frame 
languages support this style of program¬ 
ming directly because of the built-in 
inheritance mechanism. 

Figure 1 shows a portion of a database 
for vehicles, represented with frames. The 
top frame describes the generic attributes 
of vehicles, such as their location, heading, 
and speed. The only operation of this slot, 
embedded in the slot named steering, 
changes the heading in some generic way. 
The frame has two subtypes, automobile 


and boat. These two frames are linked via 
the subtype relation is-a to vehicle. Is-a is 
defined such that slot existence and values 
are inherited unidirectionally from the 
relation’s range ( vehicle ) to its domain 
(automobile or boat). Thus, both automo¬ 
bile and boat have the same slots as vehi¬ 
cle. They also introduce new slots, provide 
default values for them, and override the 
generic steering function. 

The heavy-bordered frame in Figure 1, 
amphibious-vehicle, shows an example of 
multiple inheritance. An amphibious vehi¬ 
cle is both an automobile and a boat, so it 
should have a propeller and a drive axle, 
wheels and a hull. This fact is expressed 
cleanly and succinctly by making the cor¬ 
responding frame a subtype of both 
automobile and boat. Without multiple 
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inheritance, we would either have to make 
the amphibious vehicle a subtype of only 
one of its supertypes and duplicate the 
information of the other, or make the 
frame a direct subtype of vehicle and 
duplicate even more information. Clearly, 
any such duplication is undesirable. For 
example, if the type automobile or boat 
changed, we would have to update 
amphibious-vehicle manually. Dynamic 
changes (e.g., changing default values) 
would have to be anticipated with a special 
update program. 

Figure 1 also illustrates the ambiguities 
introduced by multiple inheritance. For 
amphibious-vehicle, it is unclear from 
where the steering function is inherited. 
Left-to-right breadth-first search would 
select the one from automobile, although 
a real amphibious vehicle might well need 
a special one. 

The shaded areas in Figure 1 contain 
frames that specialize vehicles to particu¬ 
lar models and frames that represent indi¬ 
vidual vehicles. The instance relation has 
the same inheritance as is-a except that 
frames already related via instance to other 


frames may not be specialized further via 
is-a or instance. Thus, instance denotes 
that a frame is a member of the set 
described by its type frame. In program¬ 
ming languages with static typing, the 
instance relation is roughly the relation 
that holds between a variable and its type, 
although inheritance of default values (like 
the value of load-cap) is generally not pos¬ 
sible in these languages. (See box below for 
a detailed comparison of inheritance 
characteristics in two representative lan¬ 
guages.) 

Classification hierarchies of inheritable 
data types are an important tool for 
programming-in-the-large. First, classifi¬ 
cation is a powerful organizational prin¬ 
ciple for large systems. Inheritable 
supertypes structure a system in a clean 
and understandable way by implementing 
and documenting the common aspects of 
multiple types in one place. Second, 
inheritable supertypes support extensibil¬ 
ity. They define incomplete open systems 
that can become components of a wide 
range of as yet unspecified future systems. 
In contrast, traditional generic or 


parameterized types (such as queues with 
their element type as a parameter) specify 
closed systems whose domain of variation 
is fixed at specification time. Third, 
inheritable supertypes support controlled 
incremental growth. A system represented 
as a classification hierarchy is extended by 
defining new subtypes. Undesired 
behavior can be replaced and new 
behavior added without affecting existing 
subtypes and instances. Fourth, main¬ 
tenance is simplified because changes need 
not be duplicated for every subtype. Also, 
the maintainer need not master every detail 
of a type when starting to change or extend 
it; the desired specialization can be built up 
step by step, while the inherited function¬ 
ality guarantees that the new subtype is at 
least partially operational at all times. For 
these reasons, languages that offer classi¬ 
fication hierarchies of inheritable types 
will gain in importance for managing the 
evolution of very large systems with a long 
lifetime. t 

User-defined relations and inheritance. 

Classification provides just one form of 


Characteristics of inheritance mechanisms 


The idea of inheritance is not unique to artificial intelli¬ 
gence. It appeared nearly simultaneously in Quillian’s 1966 
thesis and the Simula-67 programming language in 1967. 
Today, Smalltalk 6 and C+ + 7 are well-known languages that 
derive their inheritance mechanisms from Simula-67, while 
the frame languages mentioned in this article derive theirs 
from research in semantic networks. However, inheritance in 
the Simula language family is much more restricted than in 
semantic nets. Table 1 summarizes the major differences 
between C+ + and SRL, the two most recent representatives 
from the areas of programming languages and artificial intel¬ 
ligence. 

C+ + provides only two relations: the is-a relation between 
class and superclass and the instance relation between varia¬ 
ble and class. Special notations establish these relations in 
class and variable declarations. In SRL these relations are 
among over a dozen predefined relations, and the user can 
arbitrarily define many new ones. 

C+ + implements simple inheritance; that is, each class 
can have at most one superclass. Thus, the inheritance net¬ 
work forms a tree. Multiple inheritance in SRL can be used to 
combine orthogonal concepts. It is richer than simple 
inheritance since it results in an inheritance network that is 
an arbitrary, directed graph (see the frame amphibious-vehicle 
in Figure 1 as an example). Multiple inheritance cannot be 
simulated with simple inheritance except by using nested 
records and qualified names (in which case it can hardly be 
called inheritance because obtaining additional attributes is 
not implicit). 


The attributes that can be inherited differ markedly between 
the two languages. C+ + ’s inheritance can be described as 
structural because only the presence of slots and operations 
can be inherited. It is not possible to insert a value in the slot 
of a class and pass it as a default to a subclass or an 
instance. Inheritance of values is available in SRL (see the 
frame automobile in Figure 1). C+ + cannot simulate dynami¬ 
cally changing, inherited values, although inherited constants 
can be simulated with initialization procedures. 

The only mechanism for controlling inheritance in C+ + is 
to override an inherited attribute. This is adequate forC+ + , 
given the fact that the inheritance mechanism is simple and 
predefined. In SRL, one has fine control over what attributes 
get inherited and from where. One can specify which slots or 
values are included, excluded, or transformed during 
inheritance. Programmer-specified paths determine the 
source of inherited attributes. 

Classes in C+ + are static—that is, they cannot be manipu¬ 
lated at runtime. Only instance frames are variable. In SRL 
everything can change: the structure of frames, the values of 
slots, and the inheritance network. Besides allowing runtime 
change of inheritable values and inheritance paths, this flexi¬ 
bility has an additional important advantage: All frames are 
accessible and manipulate within the language. In C+ + , 
classes cannot appear as actual parameters, be assigned to 
variables, or be written to long-term store. They cannot be 
manipulated as data within the language and must instead be 
handled by special facilities in the programming environment. 
SRL avoids this limitation by treating all frames as first-class 
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inheritance, usually via the relations is-a 
and instance. The natural extension is to 
allow programmers to define their own 
relations with specific inheritance rules. 
This idea is implemented in the language 
SRL 3 and its commercial version, CRL, a 
product of Carnegie Group, Inc. 

SRL is powerful enough to define the 
semantics of all the associative links intro¬ 
duced by Quillian. Sathi, Fox, and 
Greenberg 4 have shown that SRL can 
eliminate the difficulties caused by multi¬ 
ple interpretations of is-a as noted by 
Brachman. 5 The authors carefully sepa¬ 
rate the various interpretations by defin¬ 
ing the relations is-a, instance, subset-of, 
member-of, elaboration-of, part-of, and 
revision-of (and their inverses) in SRL. 

Figure 1 illustrates the use of the relation 
revision-of. The frame Pinto-77 is linked 
via this relation to Pinto-76 and inherits 
the value of the slot manufacturer from 
there. Note that the relations is-a and 
revision-of art orthogonal. The existence 
of the slot manufacturer is inherited via is- 
a, whereas the value is inherited via 
revision-of. Sathi, Fox, and Greenberg 


provide numerous additional examples of 
programmer-defined relations. 4 

SRL allows exceptional flexibility in 
controlling inheritance. For each relation, 
the programmer can specify what is 
inherited and from where. When specify¬ 
ing what is inherited, the programmer can 
indicate explicitly which slots and values 
are included, excluded, modified, or 
added. The relations is-a and instance, for 
example, are predefined to pass all slots 
from range to domain. It is also possible 
to specify an arbitrary function for trans¬ 
forming or even synthesizing an attribute 
during inheritance. Hence, inheritance 
may automatically modify values as they 
are propagated. Finally, an optional, user- 
defined predicate for each relation deter¬ 
mines whether inheritance can actually 
take place at a given moment. 

Inheritance normally performs a 
breadth-first search from a given frame. It 
first searches the given frame, then those 
frames that are separated by one relation, 
then two, and so on. At each level, rela¬ 
tions are traversed in the order they were 
created. When searching for the value of 


a slot with some name, the programmer 
can ask for the search to stop when the first 
value is found or for a list of the values of 
all inheritable slots with that name. Fur¬ 
thermore, the programmer can constrain 
the search by specifying paths to be fol¬ 
lowed. This constraint is expressed in a 
context-free grammar of path compo¬ 
nents. It can direct the breadth-first search 
algorithm toward more fruitful areas or 
resolve ambiguities in a special way. 

Relational transitivity defines which 
relation links must be traversed in order 
for two frames to be considered related. 
For example, for frame A to be considered 
an instance of frame B, there must be a 
path from A to B that first crosses a sin¬ 
gle instance link and then any number of 
is-a links. The transitivity definition is also 
used to find all frames that are linked to a 
given frame by a particular relation. For 
example, one would search for all 
instances of automobiles with the call 
(get-relatives ’automobile ’instance) 

In Figure 1 the result would be the follow¬ 
ing list: 


objects. 

A consequence of C+ + ’s static class hierarchy is that 
inheritance is also static; that is, it can be computed before 
execution. In SRL a dynamic search algorithm is required. 

This flexibility carries a noticeable performance penalty when 
static inheritance would do. To make lookups faster, SRL 
offers an option for caching inherited attributes, but the pro¬ 
grammer is responsible for maintaining cache consistency. 
Declaring certain frames and relations static would permit 
safer ways of precomputing inheritance. 

There are no operations to manipulate relations in C+ + . 
Given the static nature of only two relations, there does not 
seem to be much need to manipulate them. However, opera¬ 
tions such as finding all instances of a certain class or testing 
whether two frames have a common superclass would be use¬ 
ful even in C+ +. In SRL the connections in a semantic net¬ 
work can be inspected, searched, and tested under program 
control. These facilities are indispensable for programs that 
interpret the structure of the network as an essential part of 
the representation. 

In C+ + , data encapsulation is static: For each class decla¬ 
ration, the programmer simply lists the fields visible to client 
programs. (Class-specific operations have full access to all 
fields.) In SRL, demons must be used for this purpose. 

Demons are predicates that check whether a particular 
access is permitted. In principle, these predicates are much 
more flexible than a list of exported field names. For instance, 
demons can distinguish between read and write access. How¬ 
ever, demons are more work to specify, and they cause con¬ 


siderable overhead in combination with inheritance. In 
practice, programmers do not use them much and leave data 
encapsulation to programming discipline. The simpler encap¬ 
sulation mechanism of C+ + is superior. 


Table 1. Inheritance characteristics. 



C+ + 

SRL 

Relations 

2 

N 


(predefined) 

(predefined and user-defined) 

Inheritance 

Simple 

Multiple inheritance 

network 

inheritance 

(tree) 

(directed graph) 

Inheritable 

Structure, 

Structure, operations, 

attributes 

operations 

values 

Inheritance 

Override 

Override, inclusion, exclusion 

control 


transformation, inheritance 
paths 

Runtime 

Instance 

All frames and 

access 

frames only 

relations 

Inheritance 

scoping 

Static 

Dynamic 

Relational 

None 

Create, delete, read, 

operations 


test, get-relatives 

Data 

encapsulation 

Static 

Dynamic 
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(Pinto-76-001, Pinto-77-112, 
Pinto-77-113, My-float-mobile) 
Finally, relation specifications are them¬ 
selves represented as frames and can be 
related to each other. This property of self¬ 
reference provides surprising flexibility. 
For example, suppose we have defined the 
relation component-of for describing the 
composition of software configurations. 
Further, we define the relations 
documentation-of, manual-of, test- 
program-of, test-result-of, and library-of 
as specializations of component-of. The 
specialization is easily described by linking 
the specifications of the extra relations via 
is-a to the specification of component-of. 
Now suppose we would like to have a pro¬ 
gram that, given a configuration frame, 
will produce a list of all its components. 
With traditional programming languages, 
one would have to write a recursive pro¬ 
gram to descend the hierarchy of compo¬ 
nents. Its body would contain a case 
statement for the alternatives of 
component-of. Whenever we added a new 
alternative, the program would have to be 
changed. In SRL, this program is a single 
line: 

(get-relatives < configuration- 
frame > ’component-of) 

For this to work properly, we need to 
specify the transitivity of component-of as 
follows: 

(repeat (step (type is-a component-of) 
t) 0 inf) 

Essentially, this specification says to fol¬ 
low arbitrarily many (0 to inf) links that 
are subclasses of component-of (including 
component-of itself). Besides being suc¬ 
cinct, this formulation has the advantage 
that it requires no reprogramming if new 
subclasses of component-of are added. 

In summary, frame languages with 
programmer-defined relations and 
inheritance provide powerful data struc¬ 
turing facilities. Relations with inheritance 
are richer than simple pointers and can 
profitably replace pointers in many linked 
data structures. Furthermore, special 
operations that exploit the properties of 
frames and relations can perform certain 
deductions automatically—for instance, 
whether two frames are related in a certain 
way or whether a frame inherits certain 
attributes. 

Common Lisp 

Lisp is the second oldest high-level pro¬ 
gramming language still in use. Only For¬ 


tran is older; Cobol is younger. The basic 
ideas of Lisp were developed by John 
McCarthy from 1956 to 1958, and the first 
implementations and tests followed 
shortly thereafter. Lisp 1 was in internal 
use at Massachusetts Institute of Technol¬ 
ogy by 1960, and Lisp 1.5 became publicly 
available in 1962. Since then, numerous 
dialects have evolved, among them Com¬ 
mon Lisp, Franz Lisp, Interlisp, MacLisp, 
Scheme, Standard Lisp, Spice Lisp, and 
ZetaLisp. Winston 8 writes about Com¬ 
mon Lisp: 

Until recently, the Lisp programming lan¬ 
guage appeared to be breaking up into many 
dialects, with no single dialect dominating all 
others. Fortunately, however, a powerful 
group of world-class programming-language 
experts, representing many key institutions, 
have designed Common Lisp, a happy amal¬ 
gam of the features provided in previous 
Lisps. We believe Common Lisp has the 
beauty to be worthy of a standard, and per¬ 
haps more importantly, we believe Common 
Lisp has the necessary documentation and 
support to be a real standard, widely 
available. 

Common Lisp 9 does indeed appear to 
have become a standard, with most 
manufacturers supporting it. I had aban¬ 
doned Lisp in the early seventies for the 
higher efficiency afforded by languages in 
the Algol family but recently rediscovered 
it through Common Lisp. All the disad¬ 
vantages that annoyed me about earlier 
Lisps have disappeared, and a well- 
defined, flexible, rich, and eminently use¬ 
ful language has emerged. 

Prejudices against Lisp revisited. To 

skeptics (like my former self) I have 
recently been saying that everything nega¬ 
tive one may know about Lisp has become 
a prejudice with respect to Common Lisp. 
The following paragraphs address that 
point. 

Efficiency. Common Lisp allows a fast, 
stack-based implementation because most 
variables are lexically scoped. The 
dynamic variable, which caused high 
interpretive overhead in earlier Lisps is still 
available, but it is the exception. A good 
Common Lisp compiler, taking advantage 
of lexical scoping and type declarations, 
achieves efficiency of numeric programs 
competitive with that of Fortran pro¬ 
grams. 9 To get the advantage of both 
interpretation and compilation, Common 
Lisp can even run in mixed mode: The pro¬ 
grammer can decide which functions to 
compile and which to interpret. 

Control structures. Early Lisps had lit¬ 


tle more than cond and a goto to specify 
control flow. Common Lisp has a com¬ 
plete and powerful set of control con¬ 
structs, including conditionals, general 
iteration constructs with multiple exits, 
specialized iteration constructs for lists, 
dynamic nonlocal exits for exception han¬ 
dling, and multivalue constructs for 
returning more than one value from a 
function. 

Data types. Common Lisp offers a rich 
set of data types and constructors. Besides 
the familiar symbols and lists we find: 
arbitrary precision integers and rational 
numbers, floating-point numbers of var¬ 
ious precisions and ranges, complex num¬ 
bers, characters and strings, vectors and 
arrays including arrays that share por¬ 
tions, records, hashtables, pathnames for 
interfacing to external file systems, and 
streams for performing I/O. The types are 
arranged in a hierarchy and come with a 
set of operations to manipulate objects of 
those types. 

Library. Early Lisps came with no 
library, so users had to write everything 
from scratch. The lack of a library stand¬ 
ard also made portability difficult. Com¬ 
mon Lisp defines a huge library. For 
example, the section on lists in the refer¬ 
ence manual lists over 70 functions, and 
the section on sequences (sequences 
encompass lists and arrays) adds another 
40 functions. 

The functions are formulated as flexibly 
as possible. Remove-if, for instance, takes 
a predicate as an argument for deciding 
whether to remove an element from a 
sequence. One can optionally specify the 
start and end points of the removal, pro¬ 
vide a maximum number of elements to be 
removed, specify whether the removal is to 
start from the front or the back, and sup¬ 
ply a function to compute a key for each 
element for testing purposes. 

Functions for sequences apply to both 
lists and arrays. Thus, an operation like 
merge or sort can be invoked on strings, 
which are vectors of characters. With this 
polymorphism users need not memorize 
multiple sets of functions for the various 
types of sequences. Of course. Common 
Lisp also contains a set specialized for 
arrays and another one for strings. 

Common Lisp also standardizes 
input/output, the file system interface 
(including remote access), and environ¬ 
ment queries. The standardization makes 
Common Lisp programs potentially more 
portable than programs in most other 
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existing languages, where these details are 
usually left to the host operating system. 

Type checking. The Common Lisp pro¬ 
grammer can specify the type of variables, 
functions, and function arguments, and a 
full interpreter will check for violations at 
runtime, while a full compiler will check 
them statically (where possible). 

Type declarations are optional and do 
not affect the meaning of a correct pro¬ 
gram. Thus, programmers have the choice 
of using or ignoring type-checking facili¬ 
ties and the choice of static or dynamic 
type checking. An implementation of 
Common Lisp is not required to perform 
these checks, so efficient interpreters can 
be built even for small machines. Com¬ 
pilers can exploit the type information to 
produce efficient code. A deficiency is per¬ 
haps that the use of type declarations and 
type checking cannot be enforced. 

Packages. Name conflicts were a fre¬ 
quent problem in earlier Lisps. Packages 
in Common Lisp create separate name 
spaces. Names can be hidden within a 
package or selectively exported, with or 
without the package name as a prefix. This 
facility is important for large, multiperson 
projects. 

Parameter lists. Common Lisp provides 
extremely flexible parameter lists. Besides 
the familiar positional parameters, there 
are keyword parameters, optional 
parameters, default values for optional 
parameters, and an indefinite number of 
parameters. 

On-line documentation. Common Lisp 
contains a simple but effective technique 
for providing on-line documentation: All 
defining forms—for example, those for 
variables, constants, types, macros, and 
functions—provide a placeholder for a 
user-supplied documentation string. 
Unlike comments, these documentation 
strings are part of the program and can be 
interrogated. For instance, the function 
describe will output the documentation 
string and other information associated 
with a symbol. Thus, one can find out 
about symbols in a large system without 
having to search text files for relevant 
comments. 

Lisp programming environments. There 
are two approaches to preparing Lisp pro¬ 
grams: structure editing and text editing. 
A hybrid approach based on the text edi¬ 
tor Emacs 10 combines the advantages of 
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both. Emacs is a general-purpose, full¬ 
screen text editor with special facilities for 
handling Lisp (and other languages as 
well). 

Balancing parentheses. A common prej¬ 
udice is that balancing parentheses in Lisp 
programs is difficult. This problem was 
eliminated years ago in Emacs as follows: 
Whenever the user types a closing 
parenthesis, the matching opening 
parenthesis is briefly highlighted. Thus, in 
order to close a list at a certain level, one 
simply types closing parentheses until the 
opening parenthesis stands out. 

Handling Lisp forms. Emacs provides 
a set of structure-oriented commands for 
manipulating entire Lisp forms, for 
instance for selecting, deleting, skipping, 
moving, copying, etc. 

Compilation/loading of changed defi¬ 
nitions. Some versions of Emacs keep 
track of the definitions that have been 
modified and can reload or recompile 
them selectively. Thus, the user does not 
have to remember which definitions were 
changed when reloading. This facility is 
similar in function to the Unix tool make, 
but operates on a finer grain. 

Automatic lookup. In an advanced Lisp 
environment, the loader and compiler will 
remember for each definition in which file 
it appeared. When asked to inspect or edit 
a function, the editor can find out where 
the function definition originated and 
position the editing buffer over the defi¬ 
nition. 

Interactive interpreters. In my preoccu¬ 
pation with purely compiled languages for 
many years, I had forgotten the superiority 


of interactive interpreters. The fact that 
program and data structures are open to 
inspection and use at any time has advan¬ 
tages that can hardly be overestimated. 
The best way to express these advantages 
is by pointing out what common program¬ 
ming tasks are eliminated by interactive 
interpreters: 

• There is no need to learn a separate 
command language. In compilation envi¬ 
ronments, command languages are neces¬ 
sary to combine existing programs. 
Command languages do not mesh well 
with other programming languages, pro¬ 
vide poorer data types and control struc¬ 
tures, and do not permit access to internal 
data structures of the component pro¬ 
grams. They require the programmer to be 
bilingual. In a Lisp environment, Lisp is 
also the command language. In order to 
execute a program, one simply calls it like 
any other function. In order to combine 
two functions, writing a simple nested call 
suffices, whereas a Unix programmer 
would have to use a pipe. Complicated 
combinations can be programmed within 
the language, whereas a Unix programmer 
must also master an intricate command 
language. 

• There is no need to learn a separate 
debugger. Finding out about the status of 
a program in an interactive environment 
is simple. To see the contents of a variable, 
type its name; to see what a function 
returns, type in a call to that function. All 
one needs to learn is how to inspect and 
unwind the stack and how to set break 
points and tracing. By contrast, the source 
code debuggers for most compiled lan¬ 
guages are separate systems with compli¬ 
cated interfaces, or else they are actually 
interpreters themselves. It is true that 
many Lisp systems do come with fancy 
debuggers, but one can often get by with¬ 
out them by just inspecting the program 
state with the interpreter. 

• There is no need to write drivers for 
unit testing. To test a program in an inter¬ 
active system, one simply calls the func¬ 
tions of interest. If one detects an error, 
one inspects the affected variables and 
calls additional functions to home in on 
the problem. With compiled languages, 
one always has to write a little interpreter 
for executing test scripts. These inter¬ 
preters are often trivial (“when the user 
types foo, call function foo,” etc.), but 
they do represent extra development and 
maintenance work yet are not nearly as 
flexible as interpreters for the full 
language. 
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• There is no need to write lexical 
analyzers and parsers for I/O. The Lisp 
reader is a flexible parser for reading and 
writing textual representations of any Lisp 
object. This parser is part of the language, 
and programmable to a limited but useful 
extent. In compiled languages, one has to 
write special analyzers for most input. This 
problem is addressed by special tools such 
as the Unix tools LEX and YACC or spe¬ 
cial interface description languages such as 
IDL. These tools introduce special lan¬ 
guages that must be learned. They are 
often implemented as generators that 
make debugging difficult. Maintenance 
work can be substantial if formats change. 
In Lisp one almost always gets by without 
any of that. 

Except for the last point, the above 
observations are true for most interactive 
interpreters, including Basic. There is no 
reason why interactive interpreters of simi¬ 
lar power could not be built for statically 
typed languages such as Modula-2 or Ada. 
The Rational programming environment 
for Ada is moving in this direction. 

The workstation dilemma. There is one 
important omission from Common Lisp: 
parallel processing, both coarse-grained 
and fine-grained. The lack of coarse¬ 
grained, process-level parallelism leads to 
the workstation dilemma: Each program 
is a single-user system that runs on a sin¬ 
gle workstation and is completely isolated 
from other programs. With today’s expert 
system shells, it is practically impossible to 
build distributed programs in which mul¬ 
tiple users update a shared knowledge 
base. This problem is not unique to AI, but 
it is exacerbated here because existing 
expert system shells assume that all data is 
in primary memory, which is not sharable 
among workstations. In traditional work¬ 
station environments, files on a file server 
are the sharable medium. However, Al 
systems have a voracious appetite for 
memory, and placing a knowledge base on 
a central server would certainly kill per¬ 
formance. The dilemma is clear: Either 
lose performance or lose multiuser capa¬ 
bility. 

Thus, distributed expert systems is a 
research area of high priority. We are 
presently studying how to partition seman¬ 
tic nets, how to distribute them over mul¬ 
tiple workstations, and how to support 
inheritance across these partitions. This 
approach makes it possible to place a par¬ 
tition at the node where most updates 
occur, yet still provide the necessary 
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access, at a lower bandwidth, to the rest of 
the semantic net. Migration and replica¬ 
tion of partitions are important techniques 
for improving performance. 


N atural-language 
parsers 

Machine interpretation of natural lan¬ 
guage is a research area as old as artificial 
intelligence. Whereas many problems in 
natural-language processing remain 
unsolved, advances in recent years now 
make it possible to build natural-language 
interfaces in many circumstances. The 
input to such interfaces is typed English, 
and the output is some canonical represen¬ 
tation of the input. The canonical repre¬ 
sentation is then interpreted by an 
application. The advantage of natural- 
language interfaces is that they allow com¬ 
munication with computers by casual or 
novice users who are unable or unwilling 
to learn a formal, artificial command 
language. 

I experimented with Language Craft, 
Carnegie Group’s commercial develop¬ 
ment shell for natural-language inter¬ 
faces. 11 Language Craft operates with 
case frame instantiation. Most textbooks 
on AI discuss this technique. Compared to 
earlier methods based on context-free, 
attributed grammars, case frame parsers 
are more robust and easier to program. 

The experiment consisted of building a 
natural-language help system for the set 
theory functions available in Common 
Lisp. This help system accepts questions in 
English about set operations and returns 
the names of the appropriate Common 
Lisp functions. For example, typing 

Tell me how to intersect two sets, 
produces the following function names: 


logand, intersection, nintersection 
The goal of the experiment was to assess 
the feasibility of a reusability expert—in 
other words, a program that would answer 
questions about existing software in much 
the same way as a knowledgeable pro¬ 
grammer would. The reusability expert 
differs from traditional, keyword-based 
help facilities in significant ways. First, 
keyword-based help fails if the user does 
not know the right keyword. This is often 
the case if the user is looking for some 
vaguely understood software component. 
By contrast, the reusability expert has a 
flexible natural-language interface with a 
rich synonym basis, which significantly 
broadens the scope of questions that can 
be asked and answered. Second, keyword 
lookup is often not discriminating enough. 
For instance, the keyword file may pro¬ 
duce several pages of output, leaving much 
of the selection process to the user. Ironi¬ 
cally, if one doesn’t know the right key¬ 
words, one is forced to use some general 
keyword that produces too many candi¬ 
dates. The reusability expert analyzes 
phrases rather than individual words and 
engages in a dialogue to focus on the rele¬ 
vant material. 

A difficult aspect of building a natural- 
language interface is the variability of 
expression. Synonyms are fairly easy to 
capture, but encoding the different phrase 
structures for the same meaning can be a 
lot of work. The following example sen¬ 
tences all ask for (almost) the same thing, 
without using the same terms twice: 

How would I count the elements in a 
set? 

Compute the list length. 

Tally my bitvector. 

How do I get a collection’s magnitude? 
Determine my bundle’s total count of 
items. 

How to calculate the number of bits 
in this pattern? 

The natural-language help system for 
set theory is of course far from the 
envisaged reusability expert. There are a 
total of 25 set theory functions and two 
different set representations: lists and bit- 
vectors. The help system returns the 
representation-specific functions when it 
is clear that the user is talking about one 
or the other representation (list or bitvec¬ 
tor); otherwise, it returns the functions for 
both representations (including a warning 
if there is a mixture). 

I made the following observations in the 
experiment: 
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• The syntactic coverage achievable 
with Language Craft is adequate. The 
parser recognizes 90 percent of over 300 
test sentences properly and generates the 
correct answer. The remaining sentences 
are either parsed incorrectly, incompletely, 
or they are ambiguous. 

• On the Symbolics 3640 the efficiency 
of the parser is acceptable (approximately 
four to twenty seconds real time per parse, 
depending on the length of the sentence). 

• Spelling correction works surprisingly 
well for single-word errors (although it 
slows down the parser significantly). 

• The effort required to build the gram¬ 
mar was unacceptably high compared to 
the size of the domain: The grammar is 32 
pages long and took five person-weeks to 
construct. 

Building a natural-language interface 
with Language Craft involves writing and 
debugging a context-sensitive grammar 
called a case frame grammar. A case frame 
has a distinguishing header pattern and a 
set of cases (hence the name). The header 
pattern is described by a regular grammar 
and must match the input somewhere for 
the frame to be considered for parsing. 
The cases are optional or required sentence 
fragments and are searched after a match 
for the header pattern has been found. The 
cases are either located positionally rela¬ 
tive to the match (for instance, as a posi¬ 
tional direct object following the verb) or 
by detecting a case marker. A case marker 
is a word pattern (for example, of or 
which). The case filler—the portion of the 
case that is not the marker—is another pat¬ 
tern or case frame. The output of the parse 
is the tree of case frames that match the 
input. The case frame parser automatically 
handles tenses, morphology, number (plu¬ 
ral/singular), voice (active/passive), mood 
(declarative, imperative, interrogative, 
etc.), and conjunctions. If an input is 
ambiguous, Language Craft uses its 
natural-language generation facility to 
paraphrase the multiple parses back to the 
user and asks for disambiguation. Figure 
2 shows a case frame, an input sentence, 
and the resulting output of the parser. 

In summary, building practical natural- 
language interfaces to software systems is 
feasible, but the construction of these 
interfaces is highly labor intensive, and 
powerful processors are required to 
achieve acceptable running times. How¬ 
ever, reductions in both grammar writing 
time and runtime seem achievable. 

Natural-language interfaces are meant 
only for the casual, infrequent user. Users 
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['set-cardinality* 

:type sentential 

:header count! enumerate ! number! tally 

;; header pattern with four alternatives 

:cases 

(elements 

positional direct-object 
:filler 'element* ! 'set') 

(package 

:case-marker in ! with 
:filler 'lisp')] 


['element* 

:type nominal 

:header atom ! bit! component! constituent! element! 

item ! member! one ! part ! piece ! symbol 

:cases 

(set 

:case-marker in ! of! within ! inside 
:filler 'set')] 


['set* 

:type nominal 

:header bitvector! bitstring ! bitsequence ! bunch ! 

bundle ! collection ! cluster! group ! pattern ! 
queue ! sequence ! set! string ! vector! word ....] 


['lisp' 

:type nominal 

iheader lisp ! common lisp ! clisp] 


The input ‘Count the elements of a set in lisp’ is parsed into: 

['set-cardinality* 

(%MOOD IMPERATIVE) 

(%VOICE ACTIVE) 

(%TENSE PRESENT) 

(ELEMENTS ['element* 

<%DETERMINERS DEFINITE) 

(%NUMBER PLURAL) 

(SET ['set* 

(%DETERMINERS INDEFINITE) 
(%NUMBER SINGULAR)])]) 

(PACKAGE ['lisp* 

(%NUMBER SINGULAR)])] 


Figure 2. A case frame grammar and parse. 


who work intensely with a particular sys¬ 
tem soon find typing English sentences 
tedious and prefer an artificial but terser 
command interface. However, the number 
of different systems we have to deal with 
is gradually reaching the point where we 
cannot be expected to master a special 
command language for each. As our use 
of these systems becomes more and more 
casual, the best command language may 
turn out to be natural. The final break¬ 
through will occur when the input can be 
spoken rather than typed. 


Prolog 

The programming language Prolog is a 
relatively recent development. It was 
invented by Alain Colmerauer and his col¬ 
leagues around 1970. It embodies a the¬ 
orem prover based on Kowalski’s 
procedural interpretation of Horn clause 
logic, which is in turn a refinement of 
Robinson’s unification algorithm of 1965. 
The standard textbook for Prolog is by 
Clocksin and Mellish. 12 
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In principle, Prolog departs radically 
from traditional, imperative languages. A 
program in an imperative language con¬ 
sists of instructions that compute a desired 
result. A Prolog program, in its pure form, 
does not contain explicit instructions. 
Instead, it states facts about the problem 
area as a set of logical axioms. The Prolog 
interpreter is a theorem prover that accepts 
a problem, formulated as a logical state¬ 
ment, and tries to find a constructive proof 
for it. If successful, the proof binds 
existentially quantified variables in the log¬ 
ical problem statement. The variable bind¬ 
ings are the desired results. The beauty of 
this idea is that programmers state only the 
relevant facts for the solution of a prob¬ 
lem , but not the explicit steps. Thus, Pro¬ 
log programs are declarative and therefore 
closer to specifications than programs in 
imperative languages. 

In reality, unfortunately, Prolog pro¬ 
gramming is somewhat different. It is 
generally false that the Prolog program¬ 
mer can ignore the actual steps being per¬ 
formed by the interpreter if an efficient or 
terminating computation is desired. Pro¬ 
log textbooks drop the notion of declara¬ 
tive programming fairly quickly and use 
traces to explain program behavior oper¬ 
ationally. The predicate cut and the need 
to use extralogical features like assert and 
retract further undermine the credibility of 
purely declarative programming. Perhaps 
further advances in automatic program 
transformation will allow a better approx¬ 
imation of this programming style. 

Whereas claims about declarative pro¬ 
gramming are unconvincing, Prolog is still 
an elegant and powerful language. From 
a software engineering standpoint, what 
impressed me most was the pithiness of 
Prolog, in particular its two + -for-one 
property. This property means that for 
every Prolog rule with at least one varia¬ 
ble, one would have to write two or more 
functions in a traditional language to 
obtain the same effect. This is because a 
Prolog rule with a variable can be used 
both to obtain a result (the variable bind¬ 
ing) or as a predicate that tests whether a 
given binding would satisfy the rule. 
Sometimes one can even get more than two 
for one. A good example of this property 
is append, which describes the relationship 
between two lists concatenated to form a 
third: 

append([], L, L). 

append([X|Ll], L2, [X|L3]) 
append(Ll, L2, L3). 

The first line is the boundary case, stating 


Because of its youth, 
Prolog still has a 
number of problems 
that will take some 
time to overcome. 


that any list appended to the empty list ([ ]) 
is the same list. The second line is the recur¬ 
sive case. Reading left to right, it states that 
if L3 is the concatenation of LI and L2, 
then this relation holds also if LI and L3 
are prefixed with the same element. Here 
are a few uses of append and the results: 
append([a,b], [c,d], Z) 
result: Z = [a,b,c,d] 
append([a,b], [c,d], [a,b,c,d]) 
result: true 

append([a,b], R, [a,b,c,d]) 
result: R = [c,d] 
append(L, [c,d], [a,b,c,d]) 
result: L = [a,b] 

The first use is an actual list concatenation, 
the second is a test, and the third and 
fourth deliver the missing pieces needed 
for completing a given list. In Lisp we 
would have to write four separate func¬ 
tions. What the economy of the two + -for- 
one property means for program main¬ 
tenance should be clear. 

There are two caveats regarding the 
two + -for-one property. First, we cannot 
expect miracles: Some functions have no 
inverses. For instance, when computing 
the average of a list, we cannot expect to 
get the list back by presenting the average. 
Second, for efficiency one often has to 
write explicit versions for the additional 
cases. Fortunately, however, one can 
always get the predicate for free. 

Because of its youth, Prolog still has a 
number of problems that will take some 
time to overcome. Lisp 1.5 had similar 
problems. Prolog implementations usually 
come without any library, forcing users to 
start at an extremely primitive level and 
causing portability problems. There are 
poor control constructs, an insufficient set 
of data types, and no sophisticated pro¬ 
gramming environments. An escape to 


another programming language is needed 
when one wants Prolog programs to cause 
side effects such as interacting with the 
user through windows and graphics, or to 
control a device. Fortunately for Prolog, 
efficiency is not a reason to reject it. A 
good compiler can achieve efficiency com¬ 
parable with that of an equivalent Lisp 
program. My own experience with a com¬ 
piled Prolog is that it is not more than 50 
percent slower than compiled Common 
Lisp. 

Prolog is ideal for depth-first search 
with backtracking because it has depth- 
first search in the form of Kowalski’s pro¬ 
cedural Horn clause interpretation built 
into it. For problems outside this domain, 
Prolog programs are rarely shorter or eas¬ 
ier to understand than well-written Com¬ 
mon Lisp programs. My estimation is that 
Prolog, and, more generally, logic pro¬ 
gramming, will endure and evolve but will 
gain wide acceptance only when the first 
systems of the size and complexity of an 
operating system or a DBMS have been 
built and shown to be viable. 


Production systems 

Although they are the fruit of many 
minds, production systems could well be 
named Newell machines after their main 
champion, Allen Newell. Their active 
agents are called productions, which oper¬ 
ate on a memory called a workspace. The 
workspace contains a set of data elements, 
usually records. A production consists of 
a condition/action pair, where the condi¬ 
tion is a predicate over workspace ele¬ 
ments, and the action changes the 
workspace by adding, deleting, or modify¬ 
ing elements. An important characteristic 
for von Neumann machines is that produc¬ 
tions are independent of each other. There 
is no implicit, sequential ordering as in 
most other programming languages. A 
production fires —that is, executes—its 
action as soon as its condition evaluates to 
true. 

Most production systems allow only one 
active production at a time, so there is a 
third component, called an arbiter or a 
scheduler, which resolves conflicts. 
OPS5, 13 perhaps the best-known produc¬ 
tion system, uses the following complex 
arbiter: First, a condition evaluates to true 
at most once on a given set of workspace 
elements. Hence, a production does not 
fire forever once it is enabled for the first 
time. Second, workspace elements are 
ordered according to their creation/mod- 
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ification time. This order induces a rank¬ 
ing on conflicting productions, and only 
productions enabled by the most recent 
elements are considered for firing. If there 
are several productions with the same top 
ranking, then these productions are fur¬ 
ther prioritized according to the specific¬ 
ity of their conditions: The productions 
with the highest number of tests in their 
conditions have priority. If there are still 
ties after this ordering, an arbitrary 
production is chosen to fire. 

A few production system applications 
have been notably successful. One is the 
much cited Rl, 14 a configurer of VAX 
computers implemented with OPS5. Two 
others are Mycin, for diagnosis and treat¬ 
ment of infectious blood diseases, and 
Prospector, for mineral prospecting. 
What these applications have in common 
is that they search through a flat, unstruc¬ 
tured state space. The typical production 
rule in these applications generates in 
working memory one or several successor 
states, which enable the firing of addi¬ 
tional rules. 

For general-purpose programming, 
however, production systems are awkward 
because of the lack of control structures. 
There is no two- or n-way conditional, no 
iteration, no function call, no recursion, 
no modularization. There is not even a 
sequential ordering of productions. As a 
trivial example, consider the program in 
Figure 3, which computes the factorial. In 
Lisp or Pascal a clean and clear recursive 
factorial can be written down in three 
lines; the equivalent in OPS5, exclusive of 
comments, is 26 lines. The problem with 
OPS5 here is that the program has to 
manipulate the stack explicitly. A similar 
example is iteration: An empty Pascal for- 
loop, including a declaration of the loop 
variable, takes two lines, but thirteen lines 
in OPS5. The OPS5 programmer must 
simulate control constructs with primitives 
worse than those of assembly languages. 

Because of the poor control constructs, 
OPS5 reminds me of the debate in the late 
1960’s about structured programming and 
the goto statement. Various formulations 
of the following theorem were important 
in that debate: 

Theorem: Every flowchart is equivalent 

to a while program with one occurrence 

of while-do, provided additional varia¬ 
bles are allowed. 

In his scholarly article, Harel 15 traces 
the history of this theorem back to Kleene 
and von Neumann. The theorem was 
widely used as the scientific justification 


— 


(literalize call; declaration of a stack frame for function calls 
name ; name of the function 

n ; input parameter 

result) ; value returned 

; ;production for end of recursion, computes factorial(O): 

;; if there is a call of factorial(O) with a nil result, 

;; then set the result to 1. 

(p base-step 

{(call ''name factorial 
~n 0 

''result nil) < last-call>>} 

—> 

(modify < last-call> ''result 1)) 

; ;production for recursive step: 

;; Jf there is a call of factorial(n) with n>0 and a nil result, 

■;; then generate a call for factorial^-1) with a nil result. 

(p recurse 

(call''name factorial 

''n {<n> >0} ;<n> is a local variable bound to''n 

''result nil) 

—> 

(make call ''name factorial 

''n (compute <n> - 1))) 

; ;production for return from recursive step: 

;; if there is a call of factorial(n) with n>0 and a nil result, 

;; and there is a call of factorial with a non-nil result, 

;; then set the result of the first call to n * result of the other 
;; and delete the other call. 

(p return 

{(call -'name factorial 

~n {<n> >0} 

''result nil) <current-call>} 

{(call ''name factorial 

''result {<result> > 0}) < previous-call > } 

—> 

(modify <current-call> ''result(compute <n> * <result>)) 

(remove <previous-call>)) 


Figure 3. Factorial computation in OPS5. 


for goto-less programming. However, this 
justification was mistaken, since the 
mechanical replacement of an arbitrary 
flowchart with a single while-do and addi¬ 
tional variables completely obscures the 
control flow, as pointed out by Knuth 16 in 
his excellent article on structured program¬ 
ming (pp. 273-275). 

The connection between production sys¬ 
tems and the theorem is as follows: A 
production system interpreter is exactly the 
single whi/e-do of the theorem. The inter¬ 
preter repeatedly selects a production to be 
executed by inspecting the variables in its 
workspace. Obviously, the theorem states 
that it is possible to write any program as 
a production system. However, Knuth’s 
observation about totally obscuring con¬ 


trol flow also applies. Large programs 
become flowchart emulators that are 
nearly incomprehensible. Figure 3 bears 
this out. 

After all the excitement about rule- 
based programming in recent years, actu¬ 
ally programming in OPS5 was a sobering 
experience. Since OPS5 is a pure produc¬ 
tion system without any imperative exten¬ 
sions, all the control constructs such as 
iteration, function call, recursion, and 
nested control structures have to be simu¬ 
lated. Unfortunately, the class of prob¬ 
lems where control flow is unimportant is 
quite small. Consequently, newer produc¬ 
tion systems, including the successor of 
OPS5, are hybrids. The hybrids promote 
the use of productions where appropriate 
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but permit the use of an imperative or 
functional programming language where 
productions would be awkward. 


The only way to learn 
a new programming language is by 
writing programs in it. 
—Brian Kernighan 


F rame languages with inheritance 
and sophisticated Common Lisp 
programming environments are 
the current generation of general-purpose 
power tools for programmers. Prolog and 
production systems are specialized for nar¬ 
rower problem domains. Natural- 
language parsers allow us to build sophisti¬ 
cated and productive user interfaces. If 
integrated properly, these tools together 
place exciting new software systems within 
our reach. However, the tools are neither 
intelligent nor magical; the hard part is still 
figuring out what to program. And if we 
want these programs to behave smartly, 
we have to put in the smarts ourselves. 


If this article has persuaded you to study 
some of the tools mentioned, it has served 
its purpose. Perhaps it has even persuaded 
you to take Brian Kernighan’s dictum 
seriously. □ - 
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Formalization in Programming 
Environments 

Joseph Goguen and Mark Moriconi 
SRI International 


S ince the early years of program¬ 
ming, formalization has influ¬ 
enced the evolution of program¬ 
ming environments by aiding the improve¬ 
ment of existing tools and influencing the 
development of new tools. Programming 
environments have evolved considerably 
since the years when programs were 
entered on punched cards and the main 
practical tool was a batch compiler. In the 
1960s, text editors became popular for 
program entry, and interactive tools, such 
as trace packages and interpreters, were 
developed. In the early 1970s, attention 
shifted to programming in the large and a 
variety of new tools were developed, 
including configuration and version con¬ 
trol tools, language-based editors, pret- 
typrinters, cross-reference tools, and, 
more recently, objectbases. Modern pro¬ 
gramming environments typically contain 
tools from each period, although often not 
in the forms originally conceived. 

In this article, we group tools into three 
general categories. The first contains syn¬ 
tactic tools, such as parsers, type checkers, 
pretty printers, and language-based edi¬ 
tors. The second contains semantic tools, 
such as interpreters, compilers, and pro¬ 
gram verifiers. The last contains structural 
tools, such as configuration managers, 
version control systems, and interactive 
diagramming systems. 

Formalization affects tools in all three 
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Formalization has 
contributed to the 
development of better 
tools, reusable tool 
generators, semantic 
extensions of existing 
tools, and even 
entirely new tools. 


categories. It can eliminate misunder¬ 
standings between tool users and tool 
developers, and differences between 
implementations of the same tool, espe¬ 
cially if the tool is table-driven. It can also 
contribute to the evolution of program¬ 
ming environments in the following ways: 

• It can enhance the power, efficiency, 
and adaptability of some tools. 

• It can aid the progression from one- 
of-a-kind tools to tool generators. 

0018-9162/87/1100-0055$01.00 ©1987 IEEE 


• It can enable syntactic tools to be 
enhanced with limited semantic capabili¬ 
ties, and entirely new semantic tools to be 
developed. 


Syntactic tools 

Undoubtedly, the best understood (that 
is, best formalized) aspects of program¬ 
ming environments concern syntax. In this 
section, we present formalisms for describ¬ 
ing the syntactic and type structure of pro¬ 
gramming languages, and we explain how 
these formalisms have led to practical tool 
generators for parsing, type checking, and 
language-based (structure-oriented) 
editing. 

Context-free grammars. The usual 
generative view of syntax defines a lan¬ 
guage as the set of all strings that can be 
generated or derived from a grammar. For 
present purposes, we may identify syntax 
with the context-free grammars, since 
these nearly always provide the basis for 
practical tools. Although more general 
grammars exist, including context- 
sensitive and general recursive grammars, 
processing them is too inefficient. 

In about 1956, Chomsky 1 developed 
context-free grammars for natural lan¬ 
guage syntax, including some basic mathe¬ 
matical theory. BNF (Backus-Naur form) 
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was developed in about 1960 to specify the 
syntax of Algol60 and later served as a 
convenient notation for context-free 
grammars. The syntax of programming 
languages can therefore be defined in BNF 
with the Chomsky formalism as a mathe¬ 
matical foundation. 

A context-free grammar consists of a 
finite set of nonterminal symbols (one for 
each syntactic category), a finite set of ter¬ 
minal symbols (disjoint from the nonter¬ 
minals), and a finite set of production 
rules, each having a left-hand side consist¬ 
ing of a single nonterminal and a right- 
hand side consisting of a list of terminals 
and nonterminals. In the example below, 
terminals are written in boldface and non¬ 
terminals in italics. BNF allows an 
abbreviated form in which a number of 
rules having the same left-hand nontermi¬ 
nal are collected into a single rule whose 
right-hand side contains the right-hand 
sides of the constituent rules separated by 
vertical bars, “|”. For example, an If 
statement may be defined by the rule 

if stmt if expr then stmtlist end | 

if expr then stmtlist else 
stmtlist end 

The syntactic categories are defined by the 
rules that have the corresponding nonter¬ 
minal on the left-hand side. 

A grammar is used to derive syntacti¬ 
cally correct strings, where a derivation 
from a nonterminal a is a sequence of 
strings, the first of which is a, such that 
each string is obtained from the previous 
one by substituting for one of its nonter¬ 
minal symbols the right-hand side of a rule 
that has the same nonterminal symbol as 
its left-hand side. For example, given the 
grammar above, it is possible to derive the 
string 

if x > 1 then x : = x + 1 end 
but not the string 

if x > 1 then x : = x + 1 
A string of terminal symbols belongs to the 
language defined by a grammar if and only 
if it can be derived from the grammar. 

Parsers. A parser determines whether a 
program can be derived from the grammar 
of the programming language. In a pro¬ 
gramming environment, a parser usually 
produces an abstract syntax tree for syn¬ 
tactically correct strings in which each 
node represents an operator, and its child 
nodes represent its operands. If a program 
is not syntactically correct, the parser 
should determine where the errors occur 
and give appropriate diagnostics. 



Formalization assists 
the development of 
tool generators from 
one-of-a-kind tools. 


Following the original parsers of the 
1950s, formalization paved the way for 
additional practical breakthroughs. For 
example, Knuth’s work 2 on LR grammars 
(the largest natural class of context-free 
grammars parsable with a deterministic 
pushdown automaton) and subsequent 
work on efficient LR parsing algorithms 
led to practical table-driven parsers in the 
1970s. A table-driven parser accepts a 
grammar as input and produces a parser 
for the language defined by the grammar 
as output. Prior to this breakthrough, 
building an efficient parser was a signifi¬ 
cant task. 

LR methods work on only a subset of 
the context-free grammars. A reasonably 
efficient parsing algorithm for all context- 
free grammars was developed by Earley. 3 
Such algorithms are useful for syntacti¬ 
cally extensible languages, such as ECL 4 
and OBJ. 5 

Type checkers. A type checker checks 
whether a given program satisfies the 
context-sensitive, type compatibility rules 
of a programming language. A rule might 
require, for example, that the arguments 
of a binary operator “ + ” be of the same 
type. A type error would then result from 
trying to add an integer and a real number. 
This kind of checking is called static Check¬ 
ing since it occurs prior to program execu¬ 
tion. Also, type checkers often check that 
variables are declared only once and that 
each variable used is declared. In fact, a 
type checker can be arbitrarily complex, 
depending on the notion of type. For now, 
we adopt the classical definition of type as 
a set of values. (For a brief discussion of 
different notions of type, see the sidebar 
on page 60). 

Type rules for languages are often stated 
informally in English. This practice fre¬ 
quently leads to incomplete and inconsis¬ 
tent rules, and incorrect type checkers. In 
strongly typed languages, such as Algol, 
Pascal, Modula, and Ada, each variable 
and expression in a program has a unique 


type, and the program is checked for type 
consistency between actual arguments and 
their corresponding formal arguments. 
The rules can be specified exhaustively for 
languages that have a finite set of built-in 
types and no user-defined types. Even in 
these instances, lack of formalization can 
lead to confusion, as in the arithmetic rules 
of PL/I. If user-defined types are allowed, 
the rules must be stated inductively, a 
necessity that further increases the poten¬ 
tial for error. 

Formalization has led to significant 
advances in specifying type constraints 
and mechanizing type checking. The for¬ 
malism most frequently used for specify¬ 
ing type rules is the attribute grammar , 6 a 
context-free grammar with semantic equa¬ 
tions attached to its rules. The attribute 
grammar formalism allows modular, 
syntax-driven definitions of semantic con¬ 
cepts. It can be used for any kind of static 
program analysis and has been the basis 
for many compiler-related tools, including 
table-driven language-based editors. 

As an example of an attribute grammar 
for finding undeclared variables in a pro¬ 
gram, consider the following simple lan¬ 
guage fragment: 
stmtlist -* stmt \ stmt;stmtlist 
stmt -*• r | var: = expr 
where £ denotes the empty string. We can 
annotate this grammar with semantic 
actions to determine whether variables 
that occur in assignment statements have 
been declared. To do so, we use three 
attributes— name, env, and used, where 
name is an attribute of nonterminal var, 
whose value is an identifier; env is an 
attribute of nonterminals stmt and 
stmtlist, whose value is the environment 
computed from the declarations (not 
included in the grammar above); and used 
is an attribute associated with expr, whose 
value is the set of names used in the expres¬ 
sion derived from the nonterminal. Dot 
notation indicates the value of an attribute 
associated with a syntactic category. Mul¬ 
tiple occurrences of a nonterminal in a 
production are ordered left-to-right and 
are referred to in a semantic action by 
integer subscripts, where 1 indicates the 
leftmost occurrence. Given these nota- 
tional conventions, we can detect 
undeclared variables using the following 
attribute grammar: 
stmtlist -*■ stmt; stmtlist 
stmt.env : = stmtlist\.env 
stmtlist 2 .env := stmtlist^env 
stmtlist -* stmt 
stmt.env : = stmtlist.env 
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stmt-* var :=expr 

{ var. name } U expr. used £ stmt, env 
stmt -* £ 

The actions associated with the first two 
rules say that the environment is passed 
from the left-hand side of the production 
to the right-hand side. (The environment 
is generated from declarations by similar 
rules.) The rule for assignment detects an 
undeclared variable if its semantic action 
evaluates to false. The order in which these 
rules are actually evaluated is determined 
by an evaluation scheme, several of which 
are described by Aho, Sethi, and 
Ullman. 7 Their book also provides many 
details on grammars and parsing. 

A promising alternative to attribute 
grammars is Gentzen-style inference 
rules, 8 which, like attribute grammars, 
are syntax-driven and have been used to 
define type checkers, translators, and 
other useful tools. If suitably restricted, 
such rules can be easily translated into Pro¬ 
log for execution. 

For example, to express the statement 
“expression p type checks in environment 
(context) a,” we write 

ahP 

where (- means “type checks” and p is an 
abstract syntax tree y or a typing of the 
form y :t that asserts that y has type r. An 
inference rule consists of a set of state¬ 
ments called the antecedent and a state¬ 
ment called the consequent, graphically 
separated by a horizontal line. The conse¬ 
quent of an inference rule is provable if 
each antecedent is provable. 

To define a type checker for the lan¬ 
guage fragment presented above, we use 
the following rule, which says that the 
statement var. = expr type checks in envi¬ 
ronment env if both var and expr have the 
same type t and type check in env. 

env |- var.t, env \- expr.t 
env \- var. = expr 

(Rules for constructing the environment 
are not given here.) The fact that the empty 
statement type checks in any environment 
is expressed by the axiom 

env \- £ 

Finally, a list of statements is checked by 
the rule 

env |- stmt, env \- stmtlist 
env |- stmt; stmtlist 
which says that a statement composed with 
a statement list type checks in a given envi- 


Formalization has 
enhanced syntactic 
tools with limited 
semantic capabilities 
and enabled entirely 
new semantic tools to 
be developed. 


ronment if both type check separately in 
that environment. 


Semantic tools 

Since it is much more difficult to for¬ 
malize and analyze program meaning than 
program syntax, semantic tools are fre¬ 
quently interactive rather than automatic. 
This necessity is related to the famous 
unsolvability results from classical logic, 
which show that some of the tools we most 
want, for example, termination checkers, 
cannot possibly be automatic. 

In this section, we discuss three kinds of 
programming tools that must understand 
the semantics of the language they manip¬ 
ulate. We first discuss the most widely used 
of these programming tools—interpreters 
for logic programming, which (in part) use 
logical deduction as an operational seman¬ 
tics. We next discuss the generation of 
interpreters for conventional languages 
from so-called denotational semantic defi¬ 
nitions. Such interpreters have been used 
primarily to debug large semantic defini¬ 
tions, including one for sequential Ada. 
Lastly, we describe the use of Hoare-style 
axiomatic semantic definitions in tradi¬ 
tional program verification systems. 
(Among tools not covered are program 
transformation systems, which range from 
compiler back ends 7 to systems that sub¬ 
stantially change the given data structures 
and algorithms.) 

Interpreters for logic programming. 

Logic programming is the direct use of 
logic as a programming language. A pro¬ 
gram consists of a set of axioms. Compu¬ 
tation is a constructive proof of 
consequences of the program. The two 
examples of logic programming given 


below derive from areas of logic that pre¬ 
date active research in logic programming 
systems. 

The most widely used logic program¬ 
ming language is Prolog. Its beginnings are 
widely attributed to the work of Alain Col- 
merauer and Robert Kowalski, performed 
in the early 1970s. Prolog became a prac¬ 
tical programming language in the mid- to 
late 1970s after a good compiler was devel¬ 
oped by David FI.D. Warren. The lan¬ 
guage has since been used in several areas, 
especially databases and artificial intel¬ 
ligence. 

Prolog statements are of the form 
A^B u B 2 , . . . ,B n 
where n >0 and variables are understood 
to be universally quantified. Such a state¬ 
ment is read declaratively “A is implied by 
the conjunction of the B,’s. ” Technically, 
statements of this form are called Horn 
clauses. A query is a conjunction of the 
form 

A u . . . , A„ 

where n > 0, each A, is a goal, and vari¬ 
ables are understood to be existentially 
quantified. If, for example, we are given 
axioms defining a relation sort for sorting, 
and we state a go&\sort(X,[l , 2,4]), where 
brackets indicate a list, the constructive 
proof of the goal should return the value 
[2,4,7] for X. Such proofs are performed 
using a variant of J.A. Robinson’s unifi¬ 
cation algorithm and resolution principle, 
published in 1965. Sterling and Shapiro 9 
explain the concepts behind Prolog and 
present many Prolog programs. 

Practical implementations of Prolog, 
like implementations of Lisp before it, fall 
short of the high goals of logic program¬ 
ming. For example, Prolog provides extra- 
logical predicates that achieve side effects 
outside its computational model. Extra- 
logical predicates are used for dynamically 
pruning search trees, inputting and out- 
putting, adding or deleting clauses during 
a proof, and interfacing with the operat¬ 
ing system. 

Our second example of logic program¬ 
ming is the OBJ language, 5 in which pro¬ 
grams are equations (rather than Horn 
clauses) and deductions are performed by 
term rewriting (rather than resolution). In 
contrast to Prolog, OBJ is strongly typed 
and has powerful facilities for program¬ 
ming in the large, including parameterized 
modules. We will concentrate here on 
OBJ’s model of computation, term rewrit¬ 
ing, which evolved from foundational 
research on lambda calculus beginning in 
the 1930s. 10 
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A term is constructed from function 
symbols (including constants) and vari¬ 
ables; for example, /(a:), f(f(a)), and f(g(x)) 
are terms. A rewrite rule has the form a -*■ 
p where a and p are terms, and term rewrit¬ 
ing is the replacement of an instance of the 
left-hand side of the rule by the cor¬ 
responding substitution instance of the 
right-hand side. The Church-Rosser prop¬ 
erty says that the result of executing rewrite 
rules does not depend on the ordering of 
the rewritings. The property is illustrated 
by the figure 



t 3 


in which each t, is a term and the starred 
arrows indicate 0, 1, or more steps of 
rewriting. The Church-Rosser property 
says that any two rewrite sequences start¬ 
ing from the same term (along the two 
thick arrows) can always be reconciled by 
further rewriting (along the two thin 
arrows). For a set of rewrite rules that is 
both Church-Rosser and terminating, 
every term has a unique normal form (that 
is, every execution terminates with a 
unique answer.) This feature has an 
important practical consequence: Any 
strategy for applying rewrites will give the 
same result—the one intended by the pro¬ 
grammer. The consequence holds for both 
sequential and concurrent term rewriting 
and provides a logical basis for executing 
OBJ programs efficiently.* 

Interpreters for conventional program¬ 
ming languages. An interpreter generator 
is a tool that accepts as input a semantic 
definition of a programming language and 
produces as output an interpreter for the 
language. One semantic technique suitable 
for this purpose is denotational semantics, 
developed by Chrisopher Strachey and 
Dana Scott. This technique has been used 
to define a number of programming lan¬ 
guages, including Pascal, Scheme, and 
sequential Ada. Gordon" explains 


•The actual OBJ system extends this simple model to 
include a powerful type system having user-defined 
subtypes, user-defined evaluation strategies, including 
lazy evaluation, and non-terminating programs. 


denotational semantics and gives refer¬ 
ences for further reading. 

In essence, a denotational definition is 
a recursive function from abstract syntax 
trees into well-defined semantic domains. 
The context, storage, and unrestricted 
branches (goto’s) of the denotational defi¬ 
nition must be modeled in a purely func¬ 
tional language. Mosses’ SIS system 12 
accepts as input a denotational definition 
written in the equational style of Strachey 
and executes it using a rewrite-rule seman¬ 
tics much like that explained above. 
Mosses’ next-generation system uses OBJ- 
like definitions directly. 

Program-proving systems. To verify 
that a program has a given property, we 
must prove that it does in some logic. 
Whether a formal specification of the 
property and a program in a conventional 
(nonlogical) programming language are 
consistent can be posed as a purely logical 
question using an axiomatic definition of 
language semantics in the style of 
Hoare, 13 where the notation P{S}Q 
means that, if assertion P is true before 
executing program fragment S, then asser¬ 
tion Q is true after termination of S. The 
meaning of each simple statement (such as 
assignment) is given by an axiom schema, 
and compound statements (such as state¬ 
ment composition) are given by inference 
rule schema. For example, the axiom for 
assignment without side effects is 

P[var *- expr] {var : = expr}P 
where P[var — expr] indicates the substi¬ 
tution of the expression expr for each 
occurrence of the variable var in P. The 
rule of inference for composition is 

P{stmt}R, R{stmtlist}Q 
P{stmt-stmtlist}Q 

where the horizontal line separates the 
antecedent and the consequent as before. 
A logical system containing Hoare axiom 
and inference schemas for every syntactic 
form in a programming language consti¬ 
tutes an axiomatic definition of the 
language. 

A verification condition generator 
(VCG) is the component of a program 
verification system that accepts as input a 
program and its specifications, and 
produces as output a set of lemmas that are 
free of all programming language con¬ 
structs. Proof of these lemmas guarantees 
that the specified property is satisfied by 
the program (under certain implicit 
assumptions about the computing envi¬ 
ronment). This proof is valid provided the 


VCG faithfully adheres to the axiomatic 
definition of the programming language. 
Most VCGs were built without the bene¬ 
fit of a systematic approach to the imple¬ 
mentation of Hoare schemas. Around 
1980, Moriconi and Schwartz 14 developed 
a VCG generator that accepts as input an 
axiomatic definition and produces as out¬ 
put a correct VCG for that language. (That 
is, the generated VCG accurately reflects 
the semantics of the programming lan¬ 
guage as embodied in its axiomatic defini¬ 
tion and is as powerful as the axiomatic 
definition.) The method works well with 
context-independent semantics but does 
not deal adequately with such features as 
side effects, static scope, and aliasing. 

At present, program verification sys¬ 
tems are impractical for everyday use, 
although they might be used in critical 
applications. They are impractical because 
of the inherent undecidability of whether 
programs will behave properly.* 
Behavioral properties are specified in 
undecidable theories (such as first-order 
logic) or even incomplete theories (such as 
first-order number theory). Consequently, 
mechanical theorem provers can assist in 
proofs but cannot fully mechanize them. 
In practice, a user must supply various 
additional lemmas and advice, making 
most proofs very costly. However, if the 
program property of interest is simple 
enough, both a VCG (in some form) and 
a theorem prover might be useful in a pro¬ 
gramming environment. We give some 
examples of this strategy below in our dis¬ 
cussion of the analysis of program 
structure. 

Structural tools 

The structure of a system consists of the 
relationships among system entities. 
Explicit formalizations of these relation¬ 
ships, independent of program text, have 
contributed to practical structural tools. 
We give two examples below, one that 
involves the formalization of low-level 
structural relationships and the other of 
high-level relationships. 

Version control systems. Large systems 
are built by several people over long 
periods of time and require frequent mod¬ 
ification to correct errors, adapt to chang¬ 
ing environments, and add new features. 


•A problem is decidable if and only if there exists an 
algorithm to solve it that always halts for all suitable 
inputs; if no such algorithm exists, the problem is 
undecidable. 
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Often such modifications lead to multiple 
versions of individual system components 
and hence to multiple versions of a system. 

A version control system assembles and 
maintains multiple version systems. 
Different versions of components are typi¬ 
cally differentiated using attributed trees. 


A system configuration is automatically 
assembled from a set of entities selected 
from the version trees. The purpose of the 
system configuration is to avoid unneces¬ 
sary recompilations, as well as to provide 
early (precompilation) feedback on errors. 
One difficult problem of system configu¬ 


ration is determining the direct and 
indirect effects of changes. 

The atomic entities used to formally 
describe system structure range from 
coarse-grain files and compilation units to 
finer-grain program objects such as proce¬ 
dures, functions, and variables. Logical 


Formalization and component generation 

Formalization plays a central role in the development of tion and further references on these topics, 
tool-generation systems. The input to a tool generator is Formalization has also led to interpreter generators and 

expressed in a formalism describing a language or a property prettyprinter generators. The SIS system 9 was the first tool to 
of a language. Effective tool generators hide complex generate an interpreter from a denotational definition of a pro¬ 

algorithms from the user and thereby substantially reduce the gramming language. Oppen 10 has developed a fast, language- 
effort required to implement a component. They also tend to independent prettyprinting algorithm in which specific for- 
increase standardization. Tool generators can be grouped into matting conventions are specified as an annotated sequence 
two categories—automatic tools and interactive tools. of tokens. 


Automatic tools. The effects of formalization are most evi¬ 
dent in compiling, where several production-quality tool 
generators have been developed. For example, Lex 1 generates 
a lexical analyzer from regular expressions that describe the 
tokens in a programming language, and Yacc 2 generates 
parsers from LR grammars. Type checkers have been gener¬ 
ated from attribute grammars and from the inference rules 
described by Despeyroux. 3 Most code optimizers are hand 
crafted and perform only local optimizations; Cooper, 
Kennedy, and Torczon 4 describe how the R" environment uses 
rigorous flow-analysis techniques to perform interprocedural 
optimizations for Algol-like languages efficiently. Code gener¬ 
ators have been generated by table-driven tree translation 
using techniques described by Johnson, 5 Cattell, 6 and Gra¬ 
ham and Glanville. 7 Aho, Sethi, and Ullman 8 provide informa- 
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Formalization and semantic analysis 


Formalization has led to improve¬ 
ments in and semantic extensions to 
existing tools. Sometimes formalization 
has led to entirely new tools. Some of 
the semantics-related activities that 
have benefitted from formalization are 
program construction, type checking, 
program proving, version control, inter¬ 
active diagramming, and logical pro¬ 
gramming. 

Program-construction systems. These 
systems can be classified according to 
their ability to understand the programs 
under construction. Ordinary text edi¬ 
tors have no understanding of programs; 
their operations deal with character 
deletion, insertion, and so on. 
Language-based editors use grammars 
to understand the syntactic structure of 
programs and use the underlying 
abstract syntax tree to interpret user- 
specified operations. Knowledge-based 
systems try to understand either the 
algorithmic structure of programs 1 or 
the transformation of a high-level (possi¬ 
bly nonexecutable) specification into an 
executable program. 25 These systems 
require a formal description of algorith¬ 
mic cliches and transformations, 
respectively. 

Type-checking systems. Static type 
checking has been formalized in several 
ways. If a syntactic category (stmt, 
expression, etc.) is interpreted as a type, 
one could claim that every parser does 
type checking. A more common view is 
that a type is a set of values, and type 
checking is a formalized system that 
uses attribute grammars or inference 
rules. Milner 6 describes an approach to 
type checking that allows programmers 
to avoid declaring types that can be 
inferred from context (using Robinson’s 
unification algorithm). Recently, Girard, 7 
Martin-Lof, 8 Constable, 9 Coquand and 
Huet, 10 and others have promoted the 
notion that a type is a predicate, in 
which case type checking is not static; 
in fact, if one accepts their interpreta¬ 
tion, type checking is not even decida¬ 
ble. This notion of type is used in the 
construction of programs from algo¬ 
rithm correctness proofs. 

Program-proving systems. Although 
every kind of program analysis can be 
regarded as proving something, the term 


“program proving" is used here to indi¬ 
cate a mathematical proof of con¬ 
sistency between a behavioral 
specification and a program. Boyer and 
Moore 11 have developed a notable pro¬ 
gram verification system, based on a 
logic of recursive functions inspired by 
Lisp and by McCarthy’s pioneering func¬ 
tional style of program analysis. 12 
Numerous verification systems have 
been built for Algol-like languages, 
based on the inductive assertion 
method of Floyd 13 and the axiomatic 
definitions of Hoare. 14 Practical and the¬ 
oretical work in program proving has 
spurred recent advances in version con¬ 
trol systems, interactive diagramming 
systems, logical programming, and type 
checking. A practical but less general 
approach to program analysis is to 
check assertions at runtime, a method 
employed by the Anna tools. 15 

Version-control systems. These sys¬ 
tems support the evolution of systems 
into families with multiple versions. 

Most version-control systems keep track 
of versions with attributed trees, but dif¬ 
fer in the extent to which they provide 
early (precompilation) detection of ver¬ 
sion incompatibilities. Early version- 
control systems, including Make 16 and 
its successors, 1722 grossly overestimate 
the potential effects of a change and 
then rely on the compiler to detect 
actual inconsistencies. The SVCE 
system 23,24 uses strong typing to check 
the syntactic consistency of version 
interfaces before compilation. The more 
recent Inscape system 25 uses formal 
program verification techniques to 
check very limited semantic properties 
of versions prior to compilation.- 

Interactive diagramming systems. 

These systems attempt to facilitate soft¬ 
ware design and implementation 
through various kinds of diagrams. 
Diagrammatic programming systems 
such as those developed by Reiss 26,27 
are syntactic extensions of existing 
environment tools that provide a graphi¬ 
cal interface to some underlying pro¬ 
gramming language. Diagrammatic 
design systems, on the other hand, 
should have semantic capabilities. Most 
design systems perform a syntactic 
analysis of structural diagrams that con¬ 
tain only a few (usually one or two) 


predefined relations. The PegaSys 
system 28,29 additionally manipulates dia¬ 
grams containing user-defined rela¬ 
tions; it also maintains consistency 
among diagrams and the (evolving) tar¬ 
get program, using formal program 
verification techniques. Over a dozen 
diagrammatic notations are discussed 
by Martin and McClure. 30 Most of the 
notations can be used to specify 
abstract system designs as well as con¬ 
crete implementations. 

Logical programming. Formalization 
has radically affected the design of pro¬ 
gramming languages and had an 
indirect impact on the design of envi¬ 
ronments. 

The first major development in this 
process was McCarthy’s Lisp, 31 based 
on his prior work on the logic of sym¬ 
bolic recursive functions. Pure Lisp has 
only a few basic concepts and a clear 
mathematical semantics; its interpreter 
is less than a page of code. This brevity 
and simplicity facilitated practical 
experimentation that led to the first 
interactive, integrated programming 
environments. The next major devel¬ 
opment was so-called “logic program¬ 
ming,” derived from Robinson’s 
pioneering work on resolution theorem 
proving and unification, 32 but special¬ 
ized to Horn-clause logic via SLD reso¬ 
lution. 33 The best-known embodiment of 
the logic programming paradigm is 
Prolog 34 , which has an interpreter that is 
easy to customize—for example, to 
experiment with parallel programming 
or to facilitate debugging. 35 

A third development was functional 
programming based on higher order 
rewrite rules (as in Hope 36 and 
Miranda 37 ) or on first-order equational 
logic (as in OBJ 38,39 and the work of 
Hoffman and O’Donnell 40 ). These lan¬ 
guages are executed by term rewriting. 
Recent language designs integrate 
functional programming with logic pro¬ 
gramming (for example, Eqlog 41 ) and 
functional programming with object- 
oriented programming (FOOPS 42 ). The 
languages in this third category can pro¬ 
vide good support for programming in 
the large and are expected to lead, 
along with Prolog, to radically different 
programming environments, just as Lisp 
did almost three decades ago. 
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assertions may also be used. Common 
examples of structural relations include the 
with relation between Ada compilation 
units; include compiler directives in C; 
cross-reference relations such as calls, is- 
declared-by, and is-global-to; and change 
relations such as is-added-to and is- 
deleted-from. Individual relations are 
either specified by the programmer or 
generated from the program by the version 
control system. A change to an entity 
produces an inconsistency if a specified 
relation no longer holds or if a new rela¬ 
tion is added. 

Until the late 1970s, consistency checks 
were performed by hand (possibly with the 
aid of a cross-reference listing) and by 
compilers. These methods resulted in mas¬ 
sive, unnecessary recompilations and also 
limited feedback on errors to after the fact. 
This situation has improved because of 
version control systems that can analyze 
global interface dependencies, automati¬ 
cally recompiling only the direct and 
indirect users of a changed entity. Some 
version control systems also check strong 
typing constraints and thereby guarantee 
syntactic consistency prior to compilation. 
For instance, two versions of a procedure 
may be considered syntactically consistent 
if they have the same names and the same 
number, order, and type of arguments. 
Although this type of analysis can reduce 
unnecessary recompilations and catch sim¬ 
ple errors, it is limited by the fact that two 
versions of an operation can have the same 
signature up to type equivalence but differ¬ 
ent functionality. 

Ultimately, version consistency is a 
semantic question that can only be 
resolved by formal program verification. 
We can decide whether a change to a 
procedure has global effects by the Hoare 
rule 

pre 0 \d -*■ pre new , 

pre new { operation new }post ne „, 

post„ ew — post old _ 

pre old { operation new }post old 
This rule states that if certain logical rela¬ 
tionships can be established between the 
pre- and post-assertions associated with 
the new and the old versions of an opera¬ 
tion, and if the new version satisfies its 
specifications, then the new version can be 
substituted for the old without global 
effects. (It is an instance of a general 
Hoare rule called the rule of consequence.) 
If a change does have global effects, simi¬ 
lar rules can be used to determine how far 
they propagate. This approach can be used 
for version control or any similar activity 


I 

The power, efficiency, 
and adaptability of a 
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involving assertions and programs. 
Moriconi 15 used it in a program verifica¬ 
tion system to avoid unnecessary reverifi¬ 
cation following incremental changes. 

For everyday tools, the assertion lan¬ 
guage must be carefully designed so that 
proofs in the language can be fully 
mechanized. For example, it must be pos¬ 
sible to prove the formulas pre rM -* pre new 
and post new -* post oU without user inter¬ 
vention. Thus, the assertion language must 
be selected very carefully. The Inscape ver¬ 
sion control system 16 uses a language con¬ 
sisting of variable-free and predefined 
predicates. For this simple language, 
proofs are trivial since logical implications 
can be proved by checking the subset rela¬ 
tion between sets of predicates. 

Interactive diagramming systems. A 

number of systems have been developed to 
support the construction, manipulation, 
and analysis of diagrams that describe var¬ 
ious kinds of structural relationships. 
These systems are particularly effective in 
the early stages of system design, when the 
most costly errors often occur. The most 
advanced diagramming systems provide a 
graphical editor for constructing and 
manipulating diagrams, and facilities for 
refining diagrams hierarchically and 
generating code skeletons from diagrams. 
A typical diagram is a finite, directed 
graph whose nodes denote entities and 
whose arcs denote flow relations among 
entities. The set of relations is fixed, and 
the individual relations are independent 
and atomic. Most diagramming systems 
determine whether diagrams satisfy strong 
typing constraints and whether diagram 
refinements satisfy graph connectivity 
constraints. Neither of these consistency 
checks takes any account of relation 
meaning. 

However, syntactic checks are insuffi¬ 
cient if we allow user-defined relations, 


which are desirable in a design language 
for the same reason that user-defined types 
and operations are desirable in a program¬ 
ming language. For example, a user might 
wish to define a binary connected-to rela¬ 
tion in terms of more primitive data-flow 
and control-flow relations. User-defined 
relations lead to a more complex notion of 
hierarchy in which relations considered 
atomic with respect to a level in a diagram 
may be refined into several relations at 
lower levels. Consequently, logical proofs 
are required to check interlevel consistency 
and to maintain consistency between the 
program and the diagrams that describe its 
structure. 

In the PegaSys system, 17 a user can 
define structural abstractions—namely, 
relations that denote direct connections 
among system objects—and then use them 
freely in diagrams. The levels in a diagram 
hierarchy are kept logically consistent with 
each other and with the program. Like ver¬ 
sion control systems, PegaSys depends on 
being able to decide all logical questions. 
The logical language that underlies 
PegaSys is decidable because variables in 
expressions range over the finite set of enti¬ 
ties in a system design. Whether diagrams 
and programs are consistent is also decid¬ 
able under conservative assumptions simi¬ 
lar to those made in connection with 
flow-analysis techniques for compilers. 

Limitations of 
formalization 

We have concentrated so far on the 
ways in which formalization has con¬ 
tributed to the advancement of program¬ 
ming environments. However, it is 
sometimes just as important to understand 
the limits of formalization. Here are some 
of the important ones: 

• Inherent complexity. Many problems 
are undecidable and many others are very 
hard. An environment performs a formal 
analysis of various kinds of specifications. 
This analysis can be fully automated only 
if the specification language is suitably re¬ 
stricted. Automation has been accom¬ 
plished in several areas, including parsing, 
type checking, version control, structural 
design, and, to a large extent, logical pro¬ 
gramming. 

• Notational inadequacies. Although 
better formalisms are certain to emerge as 
the field of computer science matures, the 
everyday use of formalism will still be 
limited unless a degree of informality can 
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be incorporated into descriptions of for¬ 
mal concepts. Informality is commonplace 
in everyday mathematics and, to a lesser 
extent, in programming environments that 
use techniques such as graphics. A pro¬ 
gramming environment must convert 
informal input into formal expressions for 
internal manipulation. 

• Inefficient tool generators. Tool 
generators can degrade performance. A 
system built by hand is probably always 
more efficient than a system built by a tool 
generator. However, the reduction in 
human costs offered by generators can far 
outweigh the loss in performance. 

• Incorrect specifications. Ultimately, 
a specification cannot be proven to be cor¬ 
rect. Rapid prototyping is a practical but 
partial solution to this problem. Another 
partial solution is peer review of the sort 
prevalent in mathematics. 

• Impossibility of formalizing every¬ 
thing. Software development is inherently 
a creative activity. Consequently, some 
aspects of the process will always defy for¬ 
malization. 

Promising directions 
for future research 

There are several areas where formali¬ 
zation could greatly improve and extend 


existing programming environments. 
These areas can be grouped into two 
general categories: those areas where we 
can expect formalization to lead to prac¬ 
tical results in the next decade or so, and 
those where it will clearly take longer. 

We believe that research in the follow¬ 
ing areas can lead to major advances in ten 
years or less: 

• Syntax-directed formalisms. To illus¬ 
trate syntactical tools, we discussed two 
different types of formalisms—attribute 
grammars and inference rules. Distinct 
advantages could be gained from using the 
same syntax-directed formalism for 
related environment tools. With further 
experimentation and theoretical study, 
one formalism will probably emerge as the 
best. 

• Semantic but tractable checking. We 
discussed how formalization advanced the 
fields of type checking, version control, 
and graphical diagramming. The current 
systems support decidable theories; future 
systems may be able to handle some 
interesting common cases of undecidable 
theories. 

• Incremental computing. Batch com¬ 
puting does not provide early feedback on 
errors and can be very inefficient for large 
systems. These deficiencies make 
incremental processing an attractive alter¬ 


native, especially when one considers the 
availability of free cycles on personal 
workstations. At present, incremental 
processing uses application-specific 
algorithms that often cannot be trans¬ 
ferred to other applications, even similar 
ones. A more unified and general 
approach to incremental computation is 
needed. 

• Objectbases. File systems will eventu¬ 
ally be replaced by databases, now com¬ 
monly called persistent objectbases. An 
objectbase may contain program struc¬ 
tures, compilation units, specifications, 
version and configuration information, 
etc. Current database technology is ade¬ 
quate for this task, but a more semanti¬ 
cally based approach could have many 
benefits. Prolog points in a promising 
direction, but is not quite general or effi¬ 
cient enough, and lacks a simple logical 
semantics for many of its features. 

• Rapid prototyping. The ability to 
express design decisions in a high-level 
mathematical language and then execute 
them will certainly lead to fewer costly mis¬ 
takes in the design of systems. Much prog¬ 
ress has been made in the development of 
rapid prototyping languages, such as Lisp, 
and more recently Prolog and OBJ. Log¬ 
ical languages will probably exert a great 
influence on environment design and 
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motivate the development of radically new 
architectures for their execution. 

• Program enhancement. The major 
cost of software is related to its 
enhancement—that is, its customization 
and extension. Traditional behavioral 
specifications offer little help, since bugs 
are a minor source of the cost. The prob¬ 
lem is one of scale: it is hard to understand, 
modify, and keep track of a system com¬ 
posed of many parts linked in many ways. 
Version control systems and cross- 
reference programs deal with this problem 
at one level, interactive diagramming sys¬ 
tems at another. Further efforts to formal¬ 
ize program structure and to identify 
reusable structures should be encouraged. 

It is difficult to predict what progress 
will occur beyond the next decade. How¬ 
ever, two areas of long range investigation 
deserve special mention: 

• Program development. For over 15 
years, researchers have attempted to 
codify programming knowledge in the 
form of transformations for refining an 
abstract specification into an executable 
and efficient program. Nevertheless, as 
Barstow 18 points out in a recent survey 
article, the transformational approach is 
practical at present only for programming 
in the small. We agree with the position 
recently espoused by Scherlis and Scott 19 
that research on transformations should 
focus more on the process of 
programming—the actual steps and 
insights that go into the construction of the 
final program. The research should seek 
ways to use transformations primarily to 
document and record design decisions, not 
to construct program text. 

• Program proof. Although proofs of 
program correctness are, and will remain, 
very difficult, at least two approaches may 
lead to substantial progress. The first 
approach is to employ the transformations 
that document a program derivation as a 
constructive “proof’ ’ of the end program. 
This proof would be formal if the transfor¬ 
mations preserve meaning. The second 
approach is to construct a proof and then 
derive the program from it. This approach 
relates to recent work in constructive type 
theory by Martin-Lof and many others. □ 
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Introducing Design . 

The first thinking fool 
for both sides of your brain. 



Now there's a powerful graphics and text handling 
program to help you visualize complex systems. 

Design lets you create understandable graphic 
representations of projects and processes on your 
Macintosh” or IBM® PC. So you can organize quickly, 
analyze effectively, and communicate dearly. 



Draw flow charts, organizational charts, computer 
programs, communication networks, presentation 
graphic and production line processes—in record 
time. Once you connect one object to another in a 
diagram, it stays connected, no matter where you 
move it. Design makes it easier to establish, maintain 
and understand logical relationships. 

Build Design diagrams up to 999 pages. And 
arrange them in hierarchical structure. You can also 
develop successively detailed descriptions within one 
multi-level diagram. Or hide detail, so the big picture 
is easier to see. Even edit, manipulate and stylize text 
inside any graphic object. And create "hypertext" 
links to organize text across multiple pages. 

What's mnrp vnu ran alwavs nmrarlp tn Dps inn 




Architecture is a programmable system for 


That's the verbal description of what Design can 
do. For a more graphic illustration, look to your right. 
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Design is available for the 




PC/AT and compatibles 
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Source Code 


Mark Weiser, Xerox Palo Alto Research Center 


O ne ingredient of a good program¬ 
ming environment seems to be 
access to source code. Many fine 
programming environments encourage 
full access to source (Table 1), and others 
have developed tools or cultures to get 
around the lack of source (Table 2). This 
article argues that source code is an essen¬ 
tial ingredient of good programming envi¬ 
ronments and that access to source code is 
also essential to increasing the understand¬ 
ing and use of computers in everyday life. 

I use the term source code to mean any 
program description that can automati¬ 
cally become a running program. I say 
“become” rather than “be translated 
into” in order not to exclude direct 
interpretation of the source without trans¬ 
lation. I also say “can” and not “is” so as 
not to nitpick about an ASCII string sud¬ 
denly becoming source when it is first 
translated. What distinguishes source code 
from, say, a user’s manual is that there is 
a direct connection between the source and 
what is being run on some machine and 
that this direct connection is itself subject 
to scrutiny as another piece of code. More 
on how source becomes a program and 
why it is important that this be (in princi¬ 
ple) automatic is in the next section. 

I distinguish a “source-full” from a 
“source-sparse” environment. A source- 
full environment is characterized by a high 
degree of easily available source code. The 
source need not be on line, although it 
usually is, nor need all the source be avail- 
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Programmers should 
no more be asked to 
work without access 
to source code than 
auto mechanics 
should be asked to 
work without looking 
at the engine. 


able. As a provisional definition, an envi¬ 
ronment is source-full, with respect to a 
given programming task, if (1) the source 
code is available for any similar programs 
already in the environment, and (2) the 
source code is available to any functions 
called by the program being written. 


An earlier version of this article appeared in the 
Proceedings of the First Maryland Conference on Pro¬ 
gramming Environments, May 1986; proceedings to 
be republished by Ablex Publishing, Norwood, N.J. 

0018-9162/87/1100-0066S01.00 ©1987 IEEE 


For some programming communities, 
source-full environments are a given. 
When I talk to members of the Lisp com¬ 
munity, for instance, they cannot imagine 
operating source-sparse and consider the 
whole discussion obvious and boring. Yet 
most programmers operate without access 
to the source of their operating system, 
their compiler, or even most of their appli¬ 
cations. Clearly there is something to dis¬ 
cuss, if not by the Lisp community, then 
by the rest of us. 

Many of the world’s best programmers 
work in source-full environments. Ritchie, 
Thompson, Joy, Masinter, Lampson, and 
Gosling all worked, or work, in source-full 
environments. There could be many rea¬ 
sons why good programmers and source- 
full environments go together. One rea¬ 
son, about which this article can only 
speculate but which should be the subject 
of future studies, is that source-full envi¬ 
ronments stimulate good programming 
and good programmers. A source-full 
environment might be good for program¬ 
mers because programming is a craft that 
is learned by practice and apprenticeship. 
By reading source, programmers learn 
more than just how to compute. They 
learn about design, about choices made, 
and, indirectly, about choices discarded or 
ignored. A program is a document for 
human consumption as much as it is 
instructions for a machine. The indenta¬ 
tion of the program, the choice of varia¬ 
ble names, the commenting strategy, and 
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the choice of modules are some examples 
of nonalgorithmic program features 
programmers learn about by having 
source code. 

A source-full environment is also good 
for nonprogrammers—indirectly by 
encouraging good programming and thus 
good programs but also more directly by 
providing a marketplace of resources. If 
something is wrong with a program with¬ 
out source, one can only turn to the seller 
of that program for help. With source, one 
has many avenues for seeking help: the 
daughter majoring in computer science, 
the computer fix-it shop down the street, 
a programmer at the office. With most 
products in the world the question of hav¬ 
ing a marketplace of resources does not 
even arise because there is no way to pre¬ 
vent it. Toasters do not have object code, 
and so one can take a broken toaster to a 
neighborhood shop and have it fixed. 
Even for such complex objects as televi¬ 
sion sets and automobiles, resources for 
repair and understanding are as near as the 
nearest bookstore carrying Sams Pho¬ 
tofacts or Chilton ’sAuto Repair Manual. 
The same should be true for programs (see 
the box on page 68). 

The next two sections analyze the 
important qualities of source code: truth 
and richness. (The box on page 72 dis¬ 
cusses a third advantage of source-full 
environments: the dissemination of pro¬ 
gramming culture and the reuse of code.) 
Having source code around means that 
you are closer to the truth about your 
system—closer than any manual or proof 
can bring you. Having source also enables 
you to enter the rich world of the real sys¬ 
tem or application and to understand its 
worldview, underlying assumptions, hid¬ 
den limitations, and hidden strengths. 


Table 1. How some programming environments deal with source. 


Environment 

Method of locating source 

Unix source distribution 

The use of commands find, grep, whereis 
and the establishment of well-known loca¬ 
tions in the directory tree (such as /usr/src). 

Cedar 

Mouse-select a procedure name, press 
“get” to see the abstract definition, press 
“getimpl” to see the source. 

Interlisp-D 

INSPECT function-name. 

Zetalisp 

Press meta key, mouse-select the function 
name. 

Smalltalk 

Use system browser; then use any of several 
menus to locate an implementation from a 
message. 


Table 2. Some environments without source and their workarounds. 


Environment 

Workaround 

Unix binary distribution 

User can write any command—few privileged 
commands. Source culture maintained via 
network and the many source licensees. 

Apple Macintosh 

Tools such as ResEdit and various debuggers 
(e.g., MacNosy) permit inspecting source. 
(Source is assembler language.) These tools 
widely used by Mac programmers. 


Truth 

Any programming environment, 
source-full or not, must contain descrip¬ 
tions of its components and functions. If 
it did not, these components and functions 
could not be used or reused. However, the 
source for the components and functions 
may not be available. Instead, only a 
description of the component is used—an 
abstract description I call the abstract 
interface. Abstract interface is meant 
broadly to include not just axiomatic, 
algebraic, or logical program descriptions 
but also a manual or any other program 
description that is not directly translated 
into the running code. 


When I build a cabinet, fix a car, or 
mow the lawn, I do not deal with an 
abstract interface to wood, engines, or 
grass. I confront the real thing. While an 
expert can sometimes perform miracles at 
a distance (giving instructions for fixing a 
car over the phone, for instance), most 
experts work better in the presence of the 
problem. Why? Because abstract inter¬ 
faces, whether they are proofs of correct¬ 
ness or telephoned customer descriptions, 
inevitably distort. An abstract interface 
introduces a semantic gap between its 
description and that which is described. To 
some extent this gap is good because it ena¬ 
bles the use of a new, more concise lan¬ 
guage for describing certain properties of 


the thing. The programmer can then con¬ 
centrate on “essential” aspects of a pro¬ 
gram. Furthermore, a program that 
depends only on its abstract interface is 
easier to reuse and to modify. Its internal 
aspects that do not affect the abstract 
interface can change without affecting the 
operational system. This is the familiar 
“information hiding” argument first 
introduced by Parnas, 1 and now founda¬ 
tional for such 1980s technology as Ada, 
object-oriented programming, and 
abstract data types. 

But abstract descriptions introduce an 
unbridgeable semantic gap between them¬ 
selves and the running program. No mat¬ 
ter how much we may trust the 
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programmer to have correctly captured the 
essence of the program in the abstract 
interface, the interface is not the same as 
having the program. A programmer can¬ 
not anticipate all the possible uses of a pro¬ 
gram, and unimportant details left out of 
the interface may at some later time 
become vital to an understanding of the 
program. “The map is not the territory,” 
say the general semanticists, and in this 
case, the interface is not the program. 
Maps are useful, and so are abstract inter¬ 
faces, but an abstract interface cannot 
replace access to source code any more 
than a map can replace the territory. We 
deal with our cars through abstract inter¬ 
faces called the steering wheel and the gas 
pedal. But this does not mean the rest of 
the car should or can be forever sealed 
from view. 

Is it really inevitable that there be a dis¬ 
crepancy between the interface and the 
program? Perhaps we just are not very 
good at specifying interfaces, and when we 
get very good at it we can finally be done 
with source code. Can the inevitable 
difference (because the interface must be 
different to be useful) be restricted only to 
universally irrelevant aspects, such as the 
representation of integers as big-endian or 
little-endian? No. 

The abstract interface is more than 
incomplete; it is in fact always a caricature 
of the actual code. The abstract interface 
and the program exist in different worlds, 


between which there is only the most tenu¬ 
ous connection. Consider what might 
appear to be a very tight connection: the 
abstract interface is a formal description 
of the program, and the interface has been 
“proven” to be a correct description of the 
program. Unfortunately, program proofs 
are unreliable descriptions for two rea¬ 
sons. First, proofs of programs are 
unreliable because they do not have the 
cultural checks and balances accorded 
proofs in mathematics, and even proofs in 
mathematics are unreliable. This argu¬ 
ment is cogently elaborated by DeMillo, 
Lipton, and Perlis (see box at right). The 
second reason is that mathematics is not 
the correct kind of description for pro¬ 
grams. It describes a different world, con¬ 
taining different objects, in a different 
language, than is executed by machines. 
The abstract description is a mathematical 
object (or perhaps an informal English 
object), but the program is a tangible 
object embedded in a world of physical 
interactions. 

A program proof can be false in several 
ways: 

• The proof can be wrong—that is, its 
logic is wrong; it’s not a theorem. 

• The proof can assume input condi¬ 
tions that are not always met in the 
running program. For example, the 
proof might assume that the program 
is always called with positive integers. 


but the running program has a nega¬ 
tive input. 

• The proof can be of the wrong speci¬ 
fication. For example, it correctly 
proves the program to compute 
square roots, but what was wanted is 
the log. 

• The proof can assume simplifying 
conditions about the representation 
of data—for example, that integers 
are unbounded or that reals have 
arbitrary precision. 

• The proof can assume that the pro¬ 
gram cannot be interfered with—that 
no external agent will overwrite its 
arrays or change its code. 

Any mathematical program description 
that is not itself that program (i.e., is not 
mechanically translated into, or directly 
executed as, the program) will suffer clas¬ 
sic problems of translation. In translating 
from French to English, one inevitably 
loses nuances and introduces new nuances. 
The result can still be beautiful, but it is not 
the original. The same is true for describ¬ 
ing a program in mathematics. The pro¬ 
gram is already its own description, and 
another description of the same thing will 
have disadvantages and advantages but 
will not be the same thing as the original 
program or even the original program as 
viewed through an abstract interface. 
Every language has connotations as well as 
denotations, and the former are at least as 


If kitchen appliances were like programs 


If kitchen appliances were like programs, they would all 
look alike sitting on the counter. They would all be gray, 
featureless boxes, into which one places the food to be 
processed. The door to the box, like the box itself, is com¬ 
pletely opaque. 

On the outside of each box is a general description of what 
the box does. For instance, one box might say: “Makes any¬ 
thing a meal”; another: “Cooks perfectly every time”; another: 
“Never more than 100 calories a serving.” You can never be 
exactly sure what happens to food when it is placed in these 
boxes. They don’t work with the door open, and the 200-page 
user’s manual doesn’t give any details. 

Working in a kitchen would be a matter of becoming famil¬ 
iar with the idiosyncracies of a small number of these boxes 
and then trying to get done what you really want done using 
them. For instance, if you want a fried-egg sandwich, you 
might try the “Makes anything a meal” box, since a sandwich 
is a sort of meal. But because you know from past experience 
that this box leaves everything coated with grease, you use 


the “Never more than 100 calories” box to postprocess the 
output. And so on. The result is never what you really want, 
but it is all you can do. 

You aren’t allowed to look inside the boxes to help you do 
what you really want to do. Each box is sealed in epoxy. No 
one can break the seal. If the box seems not to be working 
right, there is nothing you can do. Even calling the manufac¬ 
turer is no help, because the box is not under warranty to be fit 
for any particular purpose. The manufacturers do have help 
lines, but not for help with broken boxes—rather to help you 
figure out how to use functioning boxes. But don’t try to ask 
how your box works. The help-line people don’t know, or if they 
do, they won’t tell you. 

Several times a year you get a letter from the manufacturer 
telling you to ship them your old box and they will send you a 
new one. If you do so, you find yourself with a shinier box, 
which does whatever it did before a little faster, or perhaps it 
does a little more—but since you were never sure what it did 
before, you cannot be sure it’s better now. 
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important as the latter in human commu¬ 
nications. For instance, a program with a 
short abstract description has a connota¬ 
tion of elegance and so seems to be better 
than a somewhat longer program. Yet the 
short description may mask performance 
problems that a longer, less abstract 
description would clarify. As is true with 
translations of any sort, the many nuances 
of the original don’t survive the transfor¬ 
mation. But nuances are important. 

Mathematical descriptions are also dis¬ 
engaged from reality because reality is 
inevitably richer than what is captured 
symbolically* Mathematical integers are 
not the same as 32-bit twos-complement 
integers. Mathematical sets are not the 
same as bitmapped sets. Mathematical 
functions are not the same as computed 
functions. The reason for the differences 
is fundamental: A computer operates 
embedded in a world that we did not cre¬ 
ate and can never know completely, while 
mathematics operates in a world we 
created with known boundaries and 
assumptions. Mathematics has trouble 
enough exploring the properties of its 
restricted world—it has no hope of fully 
describing the real world. It is a useful aid 
for describing some aspects of the world, 
but as Suppe 2 points out, even mathemat¬ 
ical physics, arguably the most successful 
application of mathematics to the real 
world, works only in the context of 
elaborate boundary conditions and 
assumptions that are never fully articu¬ 
lated or explicitly recognized by the prac¬ 
titioners of that field. A computer 
program is not a formal object, nor is com¬ 
putation formal. 3 

Suppose the formal notation is itself 
directly executed? There are several sys¬ 
tems for writing programs in a language 
similar to some mathematical notation— 
for example, Fortran—but the semantics 
of Fortran programs bear only a superfi¬ 
cial resemblance to the similar-appearing 
mathematics. Prolog is a newer language 
modeled from mathematics, designed to 
resemble Horne clauses in mathematical 
logic. But Prolog the language is not the 
same as Horne clauses the notation. Pro¬ 
gramming in Prolog requires considerable 
attention to details of the embedding envi¬ 
ronment and the underlying computation 
engine. Two mathematically equivalent 


♦It is outside the scope of this article to discuss whether 
or not a symbolic description could in theory fully rep¬ 
resent reality. Since this article is about software 
engineering, it is enough to note that such a represen¬ 
tation would be wildly impractical at the present time. 


Horne clause expressions can have vastly 
different Prolog running times. Direct exe¬ 
cution of specifications, as with Prolog, 
just changes the specifications into ordi¬ 
nary programs. The specification lan¬ 
guage, however abstract and formal it 
once was, becomes just another program¬ 
ming language, with all the pitfalls and 
imprecision, but also richness and practi¬ 
cality, that go with the real world. 

Direct execution of abstract interfaces 
is another version of the automatic pro¬ 
gramming fallacy. Parnas has said that 
automatic programming is always the next 
step in computer science. In 1950 auto¬ 
matic programming meant assemblers; in 
1955 it meant compilers; and so on. 4 Per¬ 
haps now it means directly executing the 
specifications. Programming in specifica¬ 
tions remains programming—the source 
code is now in the specification language, 
but using a different language is no pana¬ 
cea for the fascinating and frustrating 
intrusion of the world into every practical 
task. 

Abstract interfaces, formal proofs, 
manuals, and documentation all remain 
distant from what the program is really 
doing. Only source code is not artificially 
distancing—when it tells a lie (e.g., 
because of a compiler bug), no principled 
barrier prevents searching out the lie; only 
limitations of time and energy (and the 
source code of the compiler) do that. This 
is a crucial distinction between an abstract 
interface and source code. The correctness 
of a system for which we have complete 
source code is in principle completely 
knowable from information internal to the 
system. The correctness of the abstract 
interface as a description of what a com¬ 
puter is doing is not an internal fact about 
the computer but depends upon bridging 
the gap between two very different worlds. 
Whether the worlds bridged are English 
and embedded programs or algebraic 
axioms and embedded programs, the 
bridging occurs outside what can be 
known within the computer system. For 
instance, if all I know of a program is its 
formal specification, then I cannot know 
how the program will behave in the pres¬ 
ence of bugs resulting from the surround¬ 
ing environment. 

Why should the process of mechanical 
translation make source code more trust¬ 
worthy than the process of human trans¬ 
lation between the specification and code? 
Compilers and hardware can, after all, 
have bugs, rendering even source inac¬ 
curate. The reason is that mechanical 
translation is, at least in principle, fully 


open for inspection to any extent desired. 
Whether or not you are in the habit of 
checking the accuracy of your compiler, 
there is a difference between knowing that 
you can inspect what it is doing and being 
completely at its mercy. There is no way to 
be sure that a program, when it is running 
in the world, corresponds to either an 


Program proving will 
never be practical 

In May 1979 a paper entitled 
“Social Processes and Proofs of The¬ 
orems and Programs” appeared in 
the Communications of the ACM. 

The authors were Richard DeMillo, 
Richard Lipton, and Alan Perlis. Their 
thesis is that proving programs cor¬ 
rect is impractical, not necessarily 
because it is too difficult, but because 
a mathematical proof can be trusted 
only when it has entered the body of 
knowledge of mathematicians. A 
proof must stand the test of time 
before any mathematician, even its 
author, will fully rely on it. Wide¬ 
spread program proving can never be 
trusted in the same way that results 
of mathematics are, say DeMillo, 
Lipton, and Perlis, because program 
proofs, applying as they do to a single 
program, are too mathematically 
uninteresting ever to enter the 
mathematical culture. Not just pro¬ 
gram proofs, but any mathematical 
proof must be interesting to be trust¬ 
worthy. 

DeMillo, Lipton, and Perlis present 
several examples of important pub¬ 
lished mathematical theorems that 
later turned out to be incorrect. For 
instance, the four-color problem was 
falsely solved many times before a 
correct solution was found just a few 
years ago. Each false result had been 
published in a major mathematical 
journal, and so presumably each had 
been read by several mathematicians. 
Eventually each was found out, in 
part because such an important 
result was subject to intense discus¬ 
sion and amplification in the commu¬ 
nity of mathematicians. It would be a 
rare program proof that could excite 
such discussion; thus it would be 
unwise to depend on mathematics to 
solve the problem of understanding 
any particular program. 
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informal or a formal description unless 
that correspondence is established 
mechanically. Even if the correspondence 
is mechanical, inspection may be 
extremely difficult if the correspondence 
checker is complex. Therefore, one cannot 
rely on the correspondence but must be 
able to inspect the result, namely the pro¬ 
gram itself. Even when it is not perfect, the 
source code of a program remains the 
closest thing to truth about how the pro¬ 
gram will run when physically embodied 
on a computer in the world. The truth 
about a program lies not in its correspon¬ 
dence with an abstract reality but in what 
happens to it in the real world. * 


Richness 

The previous section is concerned with 
the disclosure of the complete truth of a 
program. This section describes some of 
the nature of that truth—in particular that 
the meaning of a program is quite a bit 
more than its formal semantics, and that 
even nonsemantic aspects are an important 
part of the whole picture of a program. 

By richness, I mean all aspects of a pro¬ 
gram, including those without semantic 
meaning. The choice of variable names, 
the contents of comments and their style, 
and the indentation structure are all exam¬ 
ples of nonsemantic aspects that can 
nonetheless play an important role in the 
program’s maintainability, reliability, and 
basic trustworthiness. The world of source 
code is a redundant one—when one path 
to understanding fails, there is always 


*A sociological principle of trustworthiness is also at 
work here. When we have personal knowledge of a 
person, we are more willing to trust that person’s per¬ 
formance of processes that we might not be able to 
inspect directly. 1 am more willing to believe a speci¬ 
fication of a program if I know the person who wrote 
it, what the person was trying to achieve, mistakes the 
person made in the past, and so on. Most specifica¬ 
tions are not read, or written, with such intimate 
knowledge among the participants. Without this kind 
of knowledge, people put trust in procedures, laws, or 
rituals. Procedures take the place of personal knowl¬ 
edge, and trust is replaced or supplemented by the 
principle of inspectability, even if we ourselves never 


they are too large to be run by personal knowledge and 
must be run instead by procedures. If we want to trust 
programs written by people of whom we have no per¬ 
sonal knowledge, we need public, inspectable transfor¬ 
mation procedures and public inspection of the results 
of the transformation (not just the ability to execute 
the object code). 


The world of source 
code is a redundant 
one—when one path 
to understanding fails, 
there is always 
another path. 


another path. Units of compilation, choice 
of algorithm, programming tricks, and 
formal specifications and documentation 
are only some of the thousand and one 
aspects of a program that are made known 
by the source code. The world of source is 
full of clues and hints, trails and tracks, 
dead ends and superhighways. In short, it 
is a world much like the real, external 
world to which human beings are already 
well adapted. The many aspects of a pro¬ 
gram, semantic and nonsemantic, high- 
level and low-level, make up a rich, 
meaningful world in which the expert pro¬ 
grammer can dwell. An essential compo¬ 
nent of my thesis is that the redundant 
richness of the world of source substan¬ 
tially contributes to its understandability 
and to its place in our lives. 

The human mind has a propensity for a 
certain level of complexity. Too much 
complexity will drive us away, but so will 
too little. 5 People seek out and use the 
rich environment if it is available and make 
use of the clues and hints provided by such 
an environment. The full source code of a 
system is analogous to a physical world 
that the programmer can explore. Without 
source the programmer has not the real 
world but only a map. Maps can be useful, 
but they do not replace being there in 
person. 

Some of the richness of the source-full 
environment does not contribute to the 
formal meaning of the program, in the 
sense that it is thrown out by the program 
prover, compiler, or interpreter. Yet these 
nonsemantic aspects, such as comments, 
module structure, and indentation, are 
vital parts of the programming world. 
They are semantic for us, the human 
readers and doers. But one problem with 
the nonsemantic aspects of source code is 
that they can lie. Indentation can lie by dis¬ 


playing a subordinate relationship not in 
fact present in the code; modular structure 
can lie by implying an information-hiding 
discipline that may in fact be absent; cer¬ 
tainly comments can lie. Why is all this 
additional, possibly false, information not 
confusing? 

There are at least two reasons why a rich 
environment is not, in practice, confusing. 
First, people are used to dealing with a rich 
and deceptive environment. Expressway 
driving is an example. Expressway driving 
is full of deception, both deliberate (for 
example, people deliberately not signaling 
so that they can squeeze into line at an exit) 
and cognitive (the nighttime illusion that 
the road ends just beyond the headlights). 
It is certainly very rich and constantly 
changing (even more rapidly than com¬ 
puter programs). Many people don’t like 
to drive on the expressway, and not every¬ 
one can do it, but most of us can. People 
seem to prefer a certain amount of mystery 
and excitement (although not always via 
expressway driving). 6 Dealing with a rich 
and deceptive world is a basic human skill 
that should not be denied to humans work¬ 
ing as programmers. 

Second, the nonsemantic source code 
information is not particularly false. It 
may be false when interpreted as informa¬ 
tion about the program, while still being 
the truth about something in the world, 
possibly something vital to the larger con¬ 
text in which this program is running. For 
instance, poor comments might say some¬ 
thing about the quality of the programmer 
and cause the careful reader to study the 
code even more carefully. An unusual 
module structure might reveal something 
about a previous version of the system, 
providing clues to the location of future 
bugs. A misleading indentation structure 
might reveal other, as yet unmanifested, 
bugs. The source code is not always the 
place to look for information because it is 
so rich, but when one does look there, it 
can be a gold mine about what is really 
going on. 

A more mundane, but still important, 
reason for looking at source code is to dis¬ 
cover hidden limitations and hidden 
strengths. Many a compiler manual fails 
to mention that there can be, say, no more 
than 32,767 subroutines in a module. For 
every such limit, there is a programmer 
who exceeds that limit. Limits are more 
common in poorly written code, and the 
ubiquity of such code now and in the 
future might be enough to argue for ubiq¬ 
uitous source code. Yet, because no pro¬ 
gram can anticipate all its uses, even the 
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best-written program will have some 
limits. It is not possible even in principle 
to document or flag all such limits with 
error messages or comments. Some of the 
limits will depend upon a future context in 
which the program is run, a context that 
was unanticipated when the program was 
written. In the past, contextual assump¬ 
tions that have proven to be problems for 
old code in the context of new architec¬ 
tures are word size, byte order within 
words, reentrancy, and word alignment. 
As yet uninvented architectures may intro¬ 
duce their own, brand new violations of 
old assumptions. With the source code, 
there is some hope that when unantici¬ 
pated uses of a program occur, the hidden 
gotchas can be recognized, understood, or 
eliminated. 

The hidden-strength problem is less 
severe but no less frustrating. Many a pro¬ 
gram has capabilities, put into it for the 
benefit of the programmer, that by design 
or misfortune are left out of the documen¬ 
tation. Sometimes these features are 
lifesavers for the programmer, saving 
years of coding or even rescuing an entire 
project that otherwise would have been 
beyond the threshold of technical compe¬ 
tence of the available team. Hidden fea¬ 
tures can sometimes be unintentional (as 
in the generation of “useful” constants 
from unusual combinations of PDP-8 op 
codes). It is usually not good practice to 
rely on such features, but there will be 
times when the temporary use of such 
tricks can make the difference between 
profit and loss. For instance, the source 
might reveal that the representation of an 
abstract type does not use all the available 
bits. “Secretly” using one of those bits 
might save months of recoding for a new 
interface. Should the programming team 
use the bits or not? In practice, program¬ 
mers take advantage of such shortcuts all 
the time. 

Maybe no single reason given here is 
sufficient to justify source code access. But 
one reason this section is called “Rich¬ 
ness” is that it is not any single reason but 
all of them together that make a differ¬ 
ence. The programmer is not combing the 
code, looking for clues to how it works or 
what is wrong. Rather, the programmer is 
living in the “code environment,” the 
world of documents, comments, variable 
names, structure, and code that make up 
a complex program. The code environ¬ 
ment is something that one grows used to, 
and eventually expert at, without necessar¬ 
ily understanding explicitly what one 
knows. 


Source code is 
generally considered 
proprietary and is one 
of the most closely 
guarded assets of the 
software publisher. 


The dangers of source 
code 

Full access to source code has its draw¬ 
backs, among them the disclosure of pro¬ 
prietary information and the violation of 
the design principle of information hiding. 
Source code is generally considered propri¬ 
etary and is one of the most closely 
guarded assets of the software publisher. 
Publishers distribute object code instead 
of source to make it harder to duplicate the 
functionality of their product. Publishers 
that do distribute source are the exception 
(although they also seem to make money). 
This situation may be an aberration in the 
law of intellectual property that will one 
day be corrected. The law is much better 
established in the areas of patents and 
copyrights. If book publishing, for 
instance, operated under the same rules as 
program publishing, then books would be 
readable only with a special decoder. No 
one would own books; instead one would 
license them from the manufacturer, per¬ 
haps for only a limited number of read¬ 
ings. Yet, even in this age of the copier, 
book publishing companies continue to 
distribute their source and make money at 
it. The law of plagiarism in literature seems 
to provide adequate protection against not 
only verbatim copying but alsp close copy¬ 
ing of ideas and plots. 

History gives reason to hope that the sit¬ 
uation in software publishing will evolve 
toward greater access. In the first decades 
of the twentieth century, for instance, 
automobile manufacturers were very 
secretive about their designs and construc¬ 
tion methods. They couldn’t shrink-wrap 
their cars and license them (or perhaps they 
just didn’t think of it), but they used their 
own unique screws and other parts to con¬ 


trol access to the workings of their 
products. Eventually, largely due to the 
efforts of the Society for Automotive 
Engineers rather than any altruism on the 
part of the manufacturers, it was recog¬ 
nized that openness of construction 
mechanisms and standardized parts were 
of more benefit than the alternative. In the 
1920s, standardized parts and local repair 
garages became well established, appar¬ 
ently without disaster for the auto com¬ 
panies. 

The second danger of source code access 
is that it seems to violate the well- 
established principle of software design 
known as information hiding. As men¬ 
tioned earlier, information hiding is a key 
technique in today’s programming pro¬ 
cess. It shows up in languages such as Ada 
and in methodologies such as “clean- 
room” software development. 7 This is 
not the place to go into the many advan¬ 
tages one obtains from separating the 
kinds of knowledge usable by different 
aspects of a program or programming pro¬ 
cess. None of these advantages require that 
secrets be kept from human beings. Keep 
secrets from and in code, yes, so that one 
module does not depend on information 
internal to a second module, but don’t 
keep secrets from people. 

Keeping a secret in code means not per¬ 
mitting a module to use certain informa¬ 
tion that is present in other parts of a 
system. 8 A secret is kept by a module, and 
other modules may not use that secret. For 
instance, the secret may be the internal 
data structure of an abstract type. This 
does not mean that other programmers 
should not know the secret. Programmers’ 
understanding of the module may be aided 
by knowledge of its secret. Furthermore, 
relying on secrecy as a management prac¬ 
tice has many problems. What if the pro¬ 
grammer accidentally finds out the secret 
over a beer after work? Without an explicit 
discipline—telling the programmers what ■ 
the secrets are and requiring that their code 
respect the secrets—one is managing by 
throwing dice. 

Keeping secrets is aided by modern lan¬ 
guages. In most languages with abstract 
types, one can declare a routine or data to 
be private, and then other parts of the code 
may not access it. There is no harm in let¬ 
ting other programmers know about the 
data structure in principle, because they 
cannot access it. If they are not to use the 
specific data structure even implicitly in 
their code (for instance, to use random 
keys because they know the data structure 
to be a hash table rather than a linked list), 
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The programming culture and the reuse of code 


Program reuse is much on the mind of programmers these 
days. Conferences and special issues have been devoted to 
reusing programs. 1 ’ 3 Most of this work focuses on the reuse of 
programs via their abstract interfaces. But the source code 
itself is also a source of things to reuse because there is more 
to code than its functionality. And even when functionality is 
to be reused, if the desired functionality is embedded in an 
abstraction that renders it inaccessible, then source code will 
again be essential. 

It is particularly, but not exclusively, the nonfunctional 
aspects of programming that make up the programming cul¬ 
ture. Culture is an inevitable development in any group of peo¬ 
ple sharing an activity over a long period of time. Culture 
helps convey values, guides the understanding and interpreta¬ 
tion of experience, and communicates skills. Culture is a form 
of reuse, the reuse of past experience and practice by new 
members of a society. Reuse should be understood both in 
the cultural sense of sharing knowledge and practice among 
people and in the software engineering sense of physically 
reusing code. Programming consists, in part, of manipulating 
source code, so in order to have a strong, vital, and useful pro¬ 
gramming culture we must have source to share. Source ena¬ 
bles “literate” programming, as defined by Knuth. 4 Lack of 
source prevents it. 

A few of the things that can be reused besides functionality 
are variable names, variable name systems, cliches, modular 
structure, algorithms, indentation systems, performance or 
storage tricks, and language features. This is not an exhaus¬ 
tive list. 

Variable names ought to be meaningful and helpful to the 
programmer. Variable naming is an art like other linguistic 
naming arts (e.g., naming characters in a novel), and one can 
learn from examples. Variable name systems are even more 
prone to reuse, although there are not very many of them. 
Programmers I know at Management Data Systems report that 
a naming scheme for variables is used throughout the com¬ 
pany, reducing the need for comments. Charles Simonyi and 
his programmers use a naming system called “Hungarian.” 5 

Another thing to reuse is the programming cliche. 6,7 Cliches 
are idioms of programming that are not contiguous code or 
easily parameterizable and so cannot be isolated in a subrou¬ 
tine or module. An example is a linked-list search. There are 
many different ways of constructing a linked list, many differ¬ 
ent kinds of objects to link together, and many different kinds 
of searches that could be done on those lists and objects. For 
any given choice, a subroutine could be written. But most 
practicing programmers usually need to come up with their 
own code for handling linked-list searches. Yet this case is 
sufficiently common that the experienced programmer 
develops a cliche, or idiom, for writing linked-list searches, 
simplifying the job of reinventing the linked-list code each 
time. The only way to discover and reuse these cliches is to 
look at the source code. 

As more and more languages support modules, a new 
“programmer’s art" of internally organizing modules is 
developing. The external organization—by which data struc¬ 
tures and operations are made public—is accessible without 


source code. But reusing internal organization requires 
source. An example of something to be reused is the clever 
use of internal subroutines. Often one can simplify the struc¬ 
ture of a model internally by choosing the right helper rou¬ 
tines. The choice of internal data structure is also something 
that can be reused, if only one can see it. 

Obviously, one would want to reuse algorithms, and in an 
ideal world all good algorithms would be written down in 
something like the CACM Collected Algorithms. In practice, 
it can be hard to find the algorithm one wants, in part because 
the Collected Algorithms are too abstract; they apply to the 
general case and can rarely be used directly without adapta¬ 
tion and rewriting. As an alternative, a very effective search 
method is to look at an operating system to find algorithms 
relevant to operating systems, or at a statistics package to 
find algorithms relevant to statistics. By looking at a real oper¬ 
ating system or statistics package, one can be reasonably 
sure that no relevant details are missing and that all details 
present are relevant. 

Another problem with the Collected Algorithms is that not 
all useful algorithms are sufficiently general or clever to make 
it into the literature. For instance, hicks for packing records to 
save storage without hurting access are not something one 
would publish, but the good programmer can learn them from 
the source code. 

Today’s programming environments are rich with features. 
Even a relatively simple language tends to be quickly 
extended with standard subroutine libraries used by all 
programmers. A typical Unix environment, for instance, has 
over 400 documented commands and nearly 1000 separately 
documented subroutine modules. The programmer cannot 
understand all the implications of the many features of a mod¬ 
ern programming environment, even after reading the manual 
several times. Only the practice of programming, conversation 
with other programmers, and the code of other programmers 
lead to the reuse of useful programming practices, code, and 
interfaces. This happens best in source-full environments. 
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they should be told not to do so, not 
coerced by keeping the data structure 
secret. 

The cleanroom technique of Harlan 
Mills 9 consists in part of keeping separate 
the worlds of programmers and program ■ 
testers. The programmers never run their 
code, and the testers never correct code. 
But even with the cleanroom methodol¬ 
ogy, there is no reason that the program¬ 
ming environment cannot be source-full, 
with programmers looking at and learning 
from other source. The testers, for 
instance, will devise better tests if they take 
idiosyncracies of the programmer’s source 
into account. 

Another program-testing method, used 
by Panzl, 10 is the independent develop¬ 
ment of code by two programmers or pro¬ 
gramming teams. The technique is based 
on ensuring maximum differences in the 
code modules and then testing the modules 
against one another. Where they disagree, 
there is a potential problem. The United 
States space shuttle software used a simi¬ 
lar technique for backup redundancy. 
Panzl kept the teams from looking at each 
other’s code to be sure they were different. 
Another method of achieving difference 
would have been to tell the teams: “You 
may not use the same algorithms, data 
structures, tricks, or even variable names 
as the other team. Keep an eye on their 
code to be sure you don’t. ’ ’ In cases where 
the teams are working on familiar 
algorithms and data structures, this 
method of explicit difference ought to 
have advantages over Panzl’s method. 

Information hiding is especially impor¬ 
tant for larger programs. I am very sym¬ 
pathetic to the concern that large 
programs, with clean modules and inter¬ 
faces and proofs, are already hard enough 
to understand without throwing their com¬ 
plete source code in the programmer’s face 
as well. But let me turn that around: Large 
programs are hard enough to understand 
without hobbling the programmer by not 
letting out the full story as told by the 
source code. Experiments on program¬ 
mers have shown that they abstract nicely 
on their own from source code and are 
very capable of ignoring code of no 
interest even if it is scattered throughout 
a program. 11 Give the programmers the 
source, and let them make their own deci¬ 
sions about when and how to use it. 


Future directions 

Programming is less than 50 years old. 


It does not have a mature culture of its 
own, nor has society formed a final rela¬ 
tionship to it. Source code should be part 
of the programming culture, because 
source code is a rich mine of cultural gems 
for commerce among programmers. And 
source code should be a part of the wider 
culture because it demystifies program¬ 
ming and permits a marketplace of com¬ 
peting services. 

We need to focus research on the prob¬ 
lem of source code. We need to get our 
minds off the abstract and onto the con¬ 
crete world of real programmers and pro¬ 
gramming practice. There are few tools for 
managing and using source code, and even 
those tools are not widely used. 12 There 
are very few tools for doing a good job of 
searching through source code for good 
examples of data structures or even 
algorithms. And we really don’t under¬ 
stand even yet, hundreds of metrics 
later, 13 what makes a program easier to 
understand, modify, reuse, or borrow. I 
don’t think we’ll find out by looking away 
from programs to their abstract interfaces. 
The answers are in the source code. □ 
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A Practical Environment 
for Scientific Programming 

Alan Carle, Keith D. Cooper, Robert T. Hood, Ken Kennedy, Linda Torczon, 
and Scott K. Warren 
Rice University 


ince the appearance of the first r 
electronic computers over 40 years | 
ago, software for science and 
engineering has been an important con¬ 
sumer of computer resources. Almost 
every industry uses scientific software in 
the development of its products. Energy 
companies use scientific programs to simu¬ 
late the behavior of oil and gas reservoirs 
and to analyze seismic data for evidence of 
new reservoirs. The automobile and air¬ 
craft industries use very large programs to 
analyze and experiment with new vehicle 
designs. The National Center for Atmos¬ 
pheric Research is working with a com¬ 
puterized model of world weather in 
search of better weather prediction tech¬ 
niques. Computer models are also 
indispensable tools for theoretical 
biochemists, chemists, and physicists. 

The total world investment in scientific 
programs is enormous, and development 
and maintenance costs continue to grow. 
Development of scientific software 
presents most of the problems found in 
systems programming support—the codes 
are large, the interfaces are complex, and 
debugging is difficult. In addition, three 
unique aspects of scientific programming 
must be taken into consideration when 
designing support environments: 

• First, most scientific codes are written 
in Fortran and, although the language can 

November 1987 


Designed for use by 
expert programmers 
in developing and 
maintaining large 
Fortran programs, the 
R n system supports 
interprocedural 
analysis and 
optimization while 
preserving the 
efficiency of 
independent 
compilation. 


be criticized on a variety of grounds, its 
standardization together with the early 
availability of good compilers has led to a 
wide acceptance of the language by the 
numerical software community. 
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• Second, there is a vast repository of 
accumulated software, and the scientific 
community actively exchanges software, 
particularly in the form of libraries of For¬ 
tran subroutines such as Linpack and 
Eispack. 

• Third, since scientific calculations are 
extremely computation-intensive, effi¬ 
ciency of the code generated by the com¬ 
piler is critical to the Fortran programmer. 
The first Fortran compiler project imple¬ 
mented a very sophisticated optimization 
phase. Today, any manufacturer desiring 
to sell machines for scientific problem 
solving must devote significant resources 
to the development of an optimizing com¬ 
piler for Fortran. 

In spite of all the recent research activity 
on programming support environments, 
not much has been done for the support of 
scientific programming (an exception is 
Toolpack, a widely distributed library of 
programming support tools for Fortran). 
As a part of a research project on the use 
of workstations for scientific problem 
solving, we embarked in 1982 on a project 
to design and implement a software devel¬ 
opment environment, called R n , for 
numerical programmers. In addition to 
providing the usual environment tools— 
intelligent editor, debugger, database— 
we designed R" to address the three 
unique aspects of scientific programming: 
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Figure 1. An example R" display. The user is debugging a program with the execution monitor and has just requested that the 
value of alfasq be displayed. Prior to that the user had asked for help; as a result, a context-sensitive help session was initiated 
in the window at the lower right. On the left side of the screen are windows containing a composition editor and a calculator 
that manipulates exact representations of real numbers. 


Fortran, software libraries, and efficiency 
of execution. 

Of these, efficiency has had the most 
important implications for the environ¬ 
ment. In exploring ways that R n might 
help an optimizing compiler produce effi¬ 
cient code, it is reasonable to ask if there 
is any room for improvement over the very 
good code generated by today’s commer¬ 
cial compilers. The largest remaining 
impediment to high efficiency in code 
generated from Fortran is the presence of 
calls to independently compiled proce¬ 
dures. When the compiler encounters such 
a call, it must assume that every variable 
accessible to that procedure will be both 
used and changed. In other words, every 
variable in Common and every parameter 
must be assumed to be corrupted by the 


call. This assumption severely inhibits 
optimization around a procedure call. For 
example, redundant subexpression elimi¬ 
nation is an optimization in which compu¬ 
tation of a subexpression is replaced by a 
load of the value of a previously computed 
identical subexpression. When attempting 
to eliminate redundant subexpressions, the 
compiler must assume that any expression 
involving either a global variable or a for¬ 
mal parameter must be recomputed after 
a call site, severely limiting the effective¬ 
ness of this important optimization. 

These problems have been acknowl¬ 
edged by compiler writers for a long time, 
yet no general solution suitable for adop¬ 
tion into commercial compilation systems 
has emerged, in spite of the extensive liter¬ 
ature on algorithms for interprocedural 


optimization and analysis (see Richardson 
and Ganapathi’s recent bibliography 1 ). 
The problem is that interprocedural 
optimization conflicts with Fortran’s 
notion of independent compilation—the 
ability to compile a subroutine in the 
absence of any information about the pro¬ 
gram that calls it. In a typical Fortran com¬ 
pilation system the user prepares and 
compiles each of the subroutines 
separately. The program is then con¬ 
structed by joining the pieces together dur¬ 
ing the linkage edit phase. If we are to take 
advantage of knowledge about other 
procedures in the program during compi¬ 
lation, this approach is no longer feasible. 

A naive solution is to insist that the 
entire program be submitted to the com¬ 
piler at one time, enabling the compiler to 
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garner all the information it needs to per- r~ 
form interprocedural analysis and optimi- L 
zation from its reading of the code. This 
approach suffers from the drawback that 
Fortran programs often grow to hundreds 
of thousands of lines and compiling such 
a program at once would take an intoler¬ 
able length of time. One of the main rea¬ 
sons for independent compilation is to 
make it possible to rapidly reconstruct an 
executable after a change to a small part of 
the program. Our experience with the 
naive approach in PFC (Parallel Fortran 
Converter), a compilation system for par¬ 
allel computers, convinced us that simply 
reading the entire program was unreasona¬ 
bly expensive. 

A software development environment 
like R n offers an opportunity for a more 
elegant solution. If the programmer is will¬ 
ing to define which procedures constitute 
the program before compilations begin, 
then the system components can col¬ 
laborate to deliver the information needed 
to perform interprocedural analysis and 
optimization while preserving the effi¬ 
ciency of independent compilation. For 
example, the source editors can provide 
enough information about the contents of 
every procedure in a given program to per¬ 
mit the compilation system to develop 
enough information about inter¬ 
procedural dataflow to improve the qual¬ 
ity of optimization in a procedure with 
subroutine calls. In addition, the system 
can use information from the editors to 
perform sophisticated interprocedural 
optimizations. This article describes R n , 
paying particular attention to its role in the 
compilation process. 

R n overview 

R n is intended to be used by expert 
programmers in developing, testing, 
debugging, and maintaining large Fortran 
programs. The current version of the envi¬ 
ronment includes a graphical window 
manager, a database, tools for creating 
whole programs from Fortran source, 
tools for compiling these programs, and 
tools for debugging them. 

Monitor and database. The entire envi¬ 
ronment is structured as a collection of 
command processors running inside a sin¬ 
gle Unix process. A window-based moni¬ 
tor provides mechanisms to control 
subprocesses, to facilitate communication 
between command processors, and to 
manage the display, mouse, and key- 


Figure 2. Program preparation in R". 


board. It also provides a set of abstractions 
for the objects used to construct the user 
interface. Figure 1 shows an example 
display. 

The command processors use a central 
database as a long-term repository for the 
objects used in preparing and translating 
programs. This includes objects created by 
the programmer, such as source text and 
data, and objects created by the compiling 
system, such as subroutine interface infor¬ 
mation. The two principal types of objects 
stored in the database are modules and 
compositions. A module is a set of one or 
more entry points and the code to imple¬ 
ment them. Thus, a module may include 
several subroutines. The decision about 
what to include in a module is made by the 
user on the basis of preference about how 
much should go into a single editable or 
compilable unit. A composition is a hier¬ 
archical specification of a program’s struc¬ 
ture in terms of modules and other 
compositions. 

Program preparation tools. One of the 

explicit design goals for R" was to provide 
a mechanism for supporting inter¬ 
procedural analysis and optimization of 
compiled code in a practical compiling sys¬ 
tem. To achieve this, we divided the com¬ 
pilation system into two compilers: a 
program compiler, which deals solely with 
optimizations and analysis that cross 
procedure boundaries, and a module com¬ 


piler, which compiles and optimizes the 
procedures in a single module, using inter¬ 
procedural information developed by the 
program compiler. 

Similarly, to support construction of 
whole Fortran programs, R n provides a 
pair of editors: a composition editor, 
which is used to define the contents and 
structure of programs and composite 
modules, and a module editor, which is 
used to enter and modify Fortran source. 
The steps required to prepare for execution 
in R" are depicted in Figure 2. We briefly 
discuss each of these tools in the following 
paragraphs. 

Module editor. The module editor is 
intended to be the primary vehicle for edit¬ 
ing Fortran modules in the environment. 
It provides a convenient blend of structure 
and text editing, allowing the user to shift 
freely between these two paradigms. It is 
an intelligent editor that not only assists 
the programmer in producing syntactically 
correct programs but also participates in 
gathering information for use by other 
tools. The editor directly constructs an 
abstract syntax-tree representation of the 
module; this internal form for procedures 
is used throughout the environment. In 
addition, the module editor collects 
module-specific information required to 
support the interprocedural analysis and 
optimization performed in the compila¬ 
tion system. 
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Composition editor. The user creates 
and modifies compositions with the com¬ 
position editor, which checks for con¬ 
sistency (the agreement of entry point 
specifications with corresponding calls) 
and completeness (the inclusion of all 
required entry points). In essence, the 
composition editor is a syntax-directed 
editor for a module interconnection lan¬ 
guage, albeit one with a screen-oriented 
concrete syntax. The composition editor 
allows the user to conveniently complete 
a program with missing entry points by 
searching through a sequence of libraries. 
If the user wishes to take advantage of the 
support for interprocedural optimization, 
the composition of a program must be 
defined before the compilation process 
begins. 

Program compiler. The principal task 
of the program compiler is to automati¬ 
cally construct an executable image for a 
program that is, at once, fully optimized 
and fully consistent with the source code. 2 
Thus, it performs the bulk of the work of 
interprocedural analysis. This entails 
deriving a graph of the procedure call 
structure of the program, as well as com¬ 
puting summary, aliasing, and constant 
sets. The program compiler also develops 
an optimization plan for the whole pro¬ 


gram. The plan details what type of proce¬ 
dure linkage should be used for each call 
site. The actual translation of source code 
to object code for the target machine is 
performed by the module compiler. 

Module compiler. The module compiler 
resembles the optimizer and code genera¬ 
tor of a conventional compiler. It deals 
with a single module or a small collection 
of modules that are being optimized 
together because of directives provided by 
the program compiler. It translates the 
source code for the module or modules 
into optimized code for the target 
machine, capitalizing on the presence of 
interprocedural information about the 
program. The module compiler has been 
carefully designed to allow experimenta¬ 
tion with different strategies for optimiza¬ 
tion and recompilation analysis. 

Execution monitor. The execution mon¬ 
itor allows the programmer to run a pro¬ 
gram constructed by the environment. It 
provides an editor-like setting for program 
execution and debugging. For example, 
operations such as breakpoint setting or 
expression evaluation are accomplished 
with a small number of mouse selections. 
In addition, it allows a range of instrumen¬ 
tation levels, including execution of hybrid 


programs in which some modules are run 
from compiled, optimized code and other 
modules are run interpretively. Instrumen¬ 
tation levels are dynamic; the programmer 
can change them whenever execution is 
paused at a breakpoint. 

While the interprocedural information 
collected by the environment is primarily 
of interest to the optimizer, it finds appli¬ 
cation in other areas. In particular, the two 
editors and the execution monitor capital¬ 
ize on the availability of this information. 
The composition editor uses information 
about the number, type, and dimension of 
parameters to check for consistent use of 
interfaces. The module editor uses the 
same information to generate editing tem¬ 
plates for calls to known procedures. Fur¬ 
ther, if the programmer enters a literal 
constant as an argument to a subroutine 
invocation, and the parameter in that posi¬ 
tion may be modified, the editor generates 
a warning. The execution monitor uses 
interprocedural information about which 
variables may be modified by a procedure 
call to improve the efficiency of inter¬ 
preted code. This is discussed further in the 
section on the execution monitor. 

The compilation process. In designing 
the environment, one of our explicit goals 
was to distribute the program analysis 
required for optimization over the entire 
program preparation process. By carefully 
making the information flow in the envi¬ 
ronment match the steps a user takes to 
develop a program, we have been able to 
collect the requisite information efficiently 
and unobtrusively. As shown in Figure 3, 
the module editor collects local dataflow 
information and the composition editor 
collects program structure information. 
The program compiler uses this informa¬ 
tion to compute interprocedural dataflow 
information, which is then supplied to the 
module compiler. In effect, the editors 
unobtrusively record information needed 
to support optimization while the user is 
developing a program, reducing both the 
actual and the perceived expense of the 
analysis. To see this, consider the follow¬ 
ing interprocedural problem: 

Suppose we wish to determine, for each 
call site s in a procedure, the set MOD(s) 
that contains all the variables that might 
be modified upon return from the call. 
Any variable that is passed as a parameter 
to the called procedure or any variable that 
is global to the called procedure is a can¬ 
didate for MOD(s). Conventional 
optimizing compilers have no access to 
information about called procedures and 
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hence must assume that MOD(s) consists 
of all variables that are either actual 
parameters at the call site or global vari¬ 
ables of the called procedure—the only 
assumption guaranteed to be safe in these 
circumstances. 

To compute a more precise MOD(s), we 
need to look at the variables that might be 
changed, directly or indirectly, by the 
called procedure, q. Let GMOD(^) be the 
set of variables that may be changed by a 
call to q. If we can determine GMOD(qr) 
for each procedure q in the program, then 
MOD(s) for a call to q can be derived by 
determining which variables in the calling 
procedure are bound to members of 
GMODta) by the call. 

We can derive a strategy for computing 
the GMOD sets by noticing that 
GMOD(^r) consists of two components: 

• the set IMOD(^) of variables that 
might be directly modified by state¬ 
ments in q other than procedure calls, 
and 

• the set of variables that might be 
modified as a side effect of a second¬ 
ary procedure call from within q. 

The sets IMOD(<?) for each entry q in a 
module are independent of any other 
procedures in any program in which the 
module is incorporated. Hence, these sets 
can be computed by the module editor and 
stored with the module that generated 
them. From these sets GMOD(?) can be 
computed for a program by solving a 
dataflow analysis problem on the pro¬ 
gram’s call graph. Since the sets GMOD(^) 
depend on the specific call graph, they 
must be stored with the program for which 
they are computed. 

By distributing the analysis over both 
editing and compiling, we are able to 
decrease the time it requires. Because the 
editors derive initial information like the 
IMOD sets and the call graph components, 
the program compiler need not reread each 
of the procedures in the program for each 
compilation. The required local informa¬ 
tion, recorded by the editors as procedures 
are developed and modified, is saved in the 
database. The program compiler need 
only read the IMOD sets, recompute the 
interprocedural information, and recom¬ 
pile the changed subroutine along with any 
subroutines for which interprocedural 
information has changed. This avoids the 
necessity to read the source of every mod¬ 
ule in the program at each compilation, a 
real savings. (The subject of limiting the 
number of recompilations is discussed 
under “Whole-program analysis and 


Users encounter 
problems with 
structure editors for 
various reasons, 
mainly because such 
editors deal with trees 
that look like text. 


optimization.”) 

These observations illustrate an impor¬ 
tant aspect of the division of labor in R". 
In addition to parsing and type checking, 
the editors can gather most of the informa¬ 
tion needed to support interprocedural 
analysis. An independent process can then 
compute the interprocedural side effects 
for the whole program. Because the anal¬ 
ysis of these side effects does not depend 
on output from the compiler, the environ¬ 
ment can compute interprocedural infor¬ 
mation for each entry point in the program 
before any module is compiled. 


R" editors 

In this section we describe in more detail 
the two editors used to prepare programs 
in R n . The purpose of this discussion is to 
illustrate the philosophy behind the design, 
rather than to provide a level of detail 
more suitable for a user’s manual. Hence, 
our focus is on the functions performed by 
these editors and on our principal design 
decisions. 

Module editor. As discussed in the 
previous section, the module editor not 
only is used for entering source text, it also 
plays a major role in gathering informa¬ 
tion to support the compilation process. In 
the R" database all modules are repre¬ 
sented as abstract syntax trees. The editor 
is responsible for producing such trees as 
a by-product of the editing process. In 
addition, the editor must produce infor¬ 
mation about the usage of variables in the 
program as an input to interprocedural 
analysis. Such information can be gained 
only by examining the program in parsed 
form. 

Since we needed to have the program in 
parsed form, it seemed logical to design the 
module editor as a structure editor, one in 
which the user enters whole syntactic con¬ 


structs into a tree. In a typical structure 
editor the program is entered through a 
series of steps in which the user expands a 
placeholder template at each step. For 
example, the user might wish to expand the 
nonterminal < statement > into a 
< conditional statement >. After execut¬ 
ing the command to do this, the statement 
placeholder is replaced by an If-Then-Else 
template that contains placeholders for the 
conditional expression, the Then state¬ 
ment list, and the Else statement list. 
Hence, the program is developed from the 
top down by means of a system based on 
the grammar of the language. 

Structure editors have many advan¬ 
tages. They assist the programmer in cor¬ 
rectly entering unfamiliar statements and 
moving entire syntactic structures around 
the program. As an additional advantage 
from the implementor’s standpoint, they 
obviate the need for a source language 
parser. (R n includes a parser to allow 
importing of programs developed under 
other systems.) 

Unfortunately, users find structure edi¬ 
tors awkward for a variety of reasons. The 
main problem is that such editors deal with 
trees that look like text. Hence, the rules 
concerning legal and illegal operations are 
far from self-evident. For example, there 
are parts of the displayed text that cannot 
be edited, namely the fixed tokens in a 
template. The user who wishes to convert 
an If statement to a While statement soon 
discovers that changing the If token will 
not work. In fact, this change requires a 
nonintuitive sequence of transformations 
that are far more complex than the oper¬ 
ation deserves. Another problem with 
structure editors is that the cursor motion 
commands are difficult to deal with 
because they represent motion in trees. 
Our original editor provided a partial solu¬ 
tion by relying on point-and-click seman¬ 
tics using a mouse, but this was not 
sufficient for the sophisticated user who 
wants to move the cursor without leaving 
the keyboard. 

For these reasons we have completely 
reimplemented the R n module editor to 
accommodate a style that mixes the text 
and structure paradigms. This solution 
retains most of the advantages of structure 
editing while providing a much more 
understandable interface to the user. The 
new editor has all the capabilities of the old 
editor but can be used as a pure text edi¬ 
tor as well. Furthermore, there is a natu¬ 
ral and helpful connection between text 
and structure. The user who wishes to get 
a template for a particular construct need 
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(1) Enter the statement: 

a(i) = b(i) - c(i) 

(2) Insert do 100 i = 1,100 before this statement: 

do 100 i = 1,100 
*** ERROR, NO END OF LOOP 
a(i) = b(i) - c(i) 


(3) Insert 100 continue after the assignment to get: 

do 100 i = 1,100 


(4) Select a portion of the assignment statement: 

do 100 i = 1,100 
a(i) = b(i) - c(i) 

100 continue 


(5) Do a More: 


100 


do 100 i = 1,100 
a(i) = b(i) - c(i) 
continue 


(6) Do a Clip and enter a(i -1): 

do 100 i = 1,100 
a(i) = a(i — 1 ) 
100 continue 


(7) Select after the assignment, do an Expand, and select an “arithmetic if” from the menu- 

do 100 i = 1,100 
a(i) = a(i — 1 ) 

if (<expression>) <label>, <label>, <label> 

100 continue 


(8) Change do 100 i = 1,100 to if (b(i) .le. a(i)) to get: 

if (b(i) .le. a(i)) 

*** ERROR, NO ENDIF 
a(i) = a(i — 1 ) 

'*(<expression>) <label>, <label>, <label> 
100 continue 

(9) Change the continue to an endif: 

if (b(i) .le. a(i)) 
a(i) = a(i— 1 ) 

„„„ if (<expression>) <label>, <label>, <label> 

100 endif 


Figure 4. A step-by-step example of text/structure editing. 


only type an unambiguous prefix and hit 
the Expand key. 

The key to the implementation is to use 
a line-oriented approach to parsing. Text 
is parsed on a line-by-line basis, with errors 
reported immediately. This is a good 
match to Fortran, with its line-oriented 
statement structure. The whole program is 
parsed in two levels—with one parse for a 
single line and a second to determine 


global program structure. After any text¬ 
editing operation is performed, the For¬ 
tran parser is invoked on the changed text 
to reconstruct the abstract syntax tree for 
the module. 

Selection in the module editor also 
employs the mixed paradigms. Textual 
selections are made simply by dragging the 
mouse over a range of characters. A More 
operation expands the selection to the 


smallest enclosing structural subtree. 
Selections can be deleted, copied, or 
pasted by making a selection from an edit 
menu or by directly entering the appropri¬ 
ate key sequence. Figure 4 illustrates the 
modification of a small program segment 
with the module editor. 

Manual view control is an important 
feature of the new module editor. The user 
specifies the view through the use of 
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explicit Conceal and Reveal commands, 
which can be applied to text ranges or 
whole substructures. If applied to sub¬ 
structures, concealment is persistent; that 
is, the concealed substructure remains con¬ 
cealed when the user scrolls to another part 
of the program and then returns. The edi¬ 
tor employs filtering mechanisms to pro¬ 
vide automatic view control. 

A final feature is of interest because of 
its use of information about the program 
that contains the module being edited. If 
the user specifies a context program in 
which the module is included and then asks 
the editor to expand a call statement, he is 
prompted with a menu of entry points 
provided in the context program. When he 
selects an entry point and expands again, 
a call template is displayed with place¬ 
holders for each parameter. The names of 
these placeholders indicate the type and 
meaning of the parameters they represent. 
This feature makes it easy for the pro¬ 
grammer to get the parameter bindings 
right without searching through the code 
of the program for the entry point code. 

Composition editor. To create a pro¬ 
gram in R", the software developer con¬ 
structs a hierarchical description known as 
a composition. A composition is simply a 
list of modules and other compositions— 
hence, a composition can be used to 
specify not only a program’s contents but 
also its structure. For example , to orga¬ 
nize the code into three phases, the pro¬ 
gram designer builds the program 
composition by including three subcom¬ 
positions, each representing one of the 
phases. 

Compositions are the basis for the con¬ 
figuration management and module inter¬ 
connection facilities in R n . Compositions 
contain the information needed to per¬ 
form efficient cross-procedural con¬ 
sistency checks. At each level of the 
composition, import and export lists pro¬ 
vide a scoping and renaming facility for 
entry point names. In essence, composi¬ 
tions provide the numerical programmer 
with a Modula-like abstraction mechanism 
without extending the base Fortran syntax. 
They can represent libraries and compos¬ 
ite modules as well as programs. 

Compositions are constructed and 
modified with the composition editor, an 
interactive editor that uses the same mix¬ 
ture of structure and text editing found in 
the module editor. The composition edi¬ 
tor checks the composition for consistency 
and completeness after each modification. 


□ 


comp QuickTest 
provides main; 

{ 

mod driver 
provides main; 
requires qsort; 
comp quicksort 

provides qsort=sort; 

/*Large-data quicksort—uses linear median finder*/ 
mod quicksort 
provides sort; 
requires median; 
comp median 
provides median; 

/*Linear median—uses bubblesort to find 
median for sets with fewer than 50 elements*/ 
mod median 
provides median; 
requires sort; 
mod bubblesort 
provides sort; 

} 

} 

} 


Figure 5. A composition. 


Consistency requires that all call site spec¬ 
ifications match the entry point specifica¬ 
tions to which they are bound and that no 
two subunits included by a composition 
export identically named routines. Com¬ 
pleteness requires that a composition 
implement all entry points that it exports, 
except those that it explicitly imports from 
some external source. 

Little distinction is made between com¬ 
posite modules, libraries, and programs. 
A composite module encapsulates a par¬ 
ticular indivisible abstraction, much as a 
Modula module does. A library is a logi¬ 
cal collection of indivisible subunits sup¬ 
porting problem solving in some domain. 
A program is simply a complete and con¬ 
sistent composition having a designated 
“main” entry point. The composition edi¬ 
tor can be used to build complete pro¬ 
grams and libraries of subroutines and to 
compose collections of subroutines and 
lower-level abstractions into new abstrac¬ 
tions. Just as easily, a complete program 
can be used as a library or as a single cohe¬ 
sive abstraction within another program. 

These ideas are best illustrated through 
an example: Suppose we are implementing 
a program that requires an efficient sort¬ 
ing routine, say Quicksort, and we wish to 


use the linear-time median-finding algo¬ 
rithm to select the pivot element. The 
median finder needs another sorting rou¬ 
tine for small sets—for example, 
Bubblesort—to deal with sets of 50 or 
fewer elements. Figure 5 shows an exam¬ 
ple composition that describes one possi¬ 
ble implementation of our sorting 
program. The innermost composition, 
named median, contains two modules 
needed for the linear median algorithm, 
median and bubblesort. This composition 
is included, in turn, in a composition 
named quicksort, which is one of the 
subunits of the outermost composition, 
named QuickTest. 

The example illustrates the facilities for 
managing name scopes. Because the pro¬ 
vides set of the composition median 
doesn’t contain sort, the entry inside mod¬ 
ule bubblesort can’t be seen outside that 
composition. Thus, it doesn’t conflict with 
the entry sort provided by the module 
quicksort. The composition quicksort, in 
turn, makes the entry sort available exter¬ 
nally under the name qsort by renaming it 
in the provides set. The example also illus¬ 
trates the power of this system for struc¬ 
tural description. The median finder is 
encapsulated into one composition while 
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Figure 6. Organization of the execution monitor. 


the main sorting procedure is encapsulated 
into another. Throughout, comments are 
used to elucidate the program map. 

Support of both bottom-up and top- 
down program development paradigms 
has been an important goal in the design 
of the composition editor. Bottom-up 
development builds programs from exist¬ 
ing code. Using the composition editor, 
the programmer can build a portion of a 
program and have the environment effi¬ 
ciently complete it by including existing 
routines with matching subroutine inter¬ 
faces from a base library or a previously 
existing program. All automatic additions 
are tentative and can be easily “undone. ’ ’ 
This scheme is ideal for constructing a new 
program that is very similar to an existing 
program or for constructing a program 
that primarily invokes common library 
routines. 

Top-down development allows the sys¬ 
tem developer to describe the entire struc¬ 
ture of a program phase by phase, before 
any Fortran code has been written; global 
storage can be defined and subroutine 
names and parameter definitions can be 
chosen. These subroutine interfaces and 
global storage definitions will be made 
available to the programmer automati¬ 
cally. In this scenario interface incon¬ 
sistencies are either avoided or 
immediately discovered. Errors are toler¬ 
ated within a composition, however, to 
support graceful changes to the top-down 
design of a system. It is possible, of course, 
to mix bottom-up and top-down develop¬ 
ment schemes. 


The execution monitor 

Design motivation. One of the major 
concerns in designing a system for debug¬ 
ging large programs is that increased 
power in the debugger slows the execution 
of the program being debugged. Although 
interpreters can provide many desirable 
features for instrumenting a running pro¬ 
gram, they are typically too slow to be seri¬ 
ously considered for debugging 
computationally intensive programs. On 
the other hand, a fully optimized program 
is exceedingly difficult to debug, primar¬ 
ily because there may be little correspon¬ 
dence between the original source and the 
program being executed. 

We need a paradigm for program exe¬ 
cution that combines the best of both exe¬ 
cution methods. If the debugger permits 
the substitution of interpreted for 
optimized code during execution, it will be 
possible to provide the increased debug¬ 
ging instrumentation precisely when it is 
needed without being penalized for it else¬ 
where. For example, if a large program has 
recently had one of its component modules 
changed, it should be possible for execu¬ 
tion to proceed quickly (via compiled 
code) to the module under development 
and at that point bring the full instrumen¬ 
tation power of an interpreter to bear. 
Such a facility would make it possible to 
implement several important features: 

Incremental modification. Having 
interpreted code in the form of an abstract 


syntax tree will make it easy to support 
modifications of the program during exe¬ 
cution. This is particularly important 
when running large programs because of 
the time required to recompile, relink, and 
return to the same point in the execution. 

Exact real arithmetic. One of the most 
promising reasons for the inclusion of 
interpreted code in large scientific pro¬ 
grams is that it will be possible to perform 
floating-point arithmetic with no round¬ 
off or representation errors. By represent¬ 
ing a real number by instructions for 
producing arbitrarily precise approxima¬ 
tions, Boehm et al. have provided a way to 
perform exact arithmetic operations on 
real numbers. 3 Because the numbers are 
not represented by finite-precision 
floating-point representations, problems 
such as roundoff errors do not occur. 
Although a severe efficiency penalty rules 
out the possibility of using the exact rep¬ 
resentation of real numbers for perform¬ 
ing all calculations in a large program, the 
techniques are perfectly adequate for 
evaluating the accuracy of answers 
obtained by conventional floating-point 
arithmetic. 

Reversible execution. Interpreted code 
will also make it feasible to support 
reverse-stepping the program counter. 
Such a facility would permit the user to 
back up execution from a fault to deter¬ 
mine what went wrong. For example, if the 
program stops because of a zero divide, the 
user could reverse-step the program 
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Table 1. Summary of implementations of Call and Return. 


Call 

To compiled 

To interpreted 

From compiled 


® • Break at first executable 


Nothing 

statement and start 
interpreting 

From interpreted 

® • Push parameters & 
return address on 
stack in child 
• Resume execution in 
compiled prologue 
code 

• Do ® then ® 


Return 

From compiled 

From interpreted 

To compiled 


© • Resume execution at 


Nothing 

compiled epilogue 
code 

To interpreted 

® • Trap on Return 

machine instruction 

• Pop parameters 

• Resume interpreter 

• Do © then ® 


counter, looking for the place where the 
denominator became zero. 

Implementation. To handle the execu¬ 
tion of compiled code, we implemented 
the execution monitor in the style of other 
Unix debuggers such as DBX and SDB— 
the debugger resides in a process that has 
the program being debugged as a child 
process. To access or change values in the 
program state of the child, the debugger 
uses a system call that enables a process 
(such as a debugger) to read and write the 
target’s address space. To determine where 
various identifiers are in the executable, it 
uses symbol table data placed in the 
executable by the compiler. Having sepa¬ 
rate address spaces for parent and child 
has the obvious advantage that the exis¬ 
tence of the debugger will not interfere 
with memory utilization in the program 
being debugged. The organization of the 
execution monitor is illustrated in Figure 6. 

To handle interpretation during pro¬ 
gram execution, the debugger process 
includes the code that implements the 
interpreter. When interpretation is 
requested, the debugger reads an abstract 
syntax tree (AST) representing the code to 
be interpreted into the address space of the 
parent process. To accomplish this, it uses 
symbol table information in the executa¬ 
ble to map from the address of an instruc¬ 
tion to the name of the object module that 
contains that address. The module name 
is then mapped to the appropriate AST in 
the database. 

To support the existence of interpreted 
and compiled code in the executable, we 
must worry about two things: the control 
flow interfaces and the data interfaces 
between the two types of code. For exam¬ 
ple, when a call is made from compiled 
code to a subprogram that is to be inter¬ 
preted, we must ensure that execution in 
the child process stops and that the inter¬ 
preter starts at the correct location in the 
forest of ASTs. In addition, references to 
data that cross the interpreted-compiled 
boundary must be handled correctly. For 
example, there may be references in com¬ 
piled code to data that is declared in a 
module being interpreted. 

Fortunately, a simple invariant makes it 
easy to avoid the data interface problems: 
The entire state of the program being 
debugged is kept in the child process. 
Thus, correct values for variables and a 
correct procedure call stack are always 
available to the compiled code in the sub¬ 
process. The other side of the coin is that, 
with this invariant, interpreted code must 


use a system call to access variable values. 
We can relax this invariant and allow cach¬ 
ing of some parts of the program state in 
the parent to improve efficiency. This will 
not cause any problems as long as the state 
of the child process is restored before any 
compiled code is executed. Furthermore, 
dataflow information provides a descrip¬ 
tion of precisely those values in the cache 
that need to be written through to the 
debugged process on entry to compiled 
code. The dataflow information also 
describes those values in the cache that 
must be refreshed after execution of the 
compiled code. 

To handle the control flow interfaces 
between interpreted and compiled code, 
we must first solve the problem of detect¬ 
ing the change and then take action to 
ensure that the invariant is maintained. 
Detecting the interfaces is trivial in inter¬ 
preted code. In compiled code, we need 
only set breakpoints at the points of inter¬ 
face. If we require that these be at state¬ 
ment boundaries, this poses no special 
problems. The hardest part of maintain¬ 
ing the invariant involves updating the 
procedure call stack in the child when a call 
or return is made. In fact, because of the 
invariant, we must also be concerned with 
calls from interpreted code to interpreted 
code. Table 1 summarizes what needs to be 
done on calls to and returns from a sub¬ 
program. In addition, Figure 7 shows an 
example of the changes in control flow on 


a call from compiled code to interpreted 
code. 

The interpreter is able to implement 
operations on variables of type Exact Pre¬ 
cision by communicating with the exact 
arithmetic server, running locally or on 
another machine on the network. The 
server program stores the exact represen¬ 
tations of the numbers. It also accepts 
requests to initialize the numbers, combine 
them with standard arithmetic operations, 
and return printable representations of 
their values. 

To maintain the invariant that requires 
the values of variables to be stored in the 
child process, after every assignment to an 
exact variable the interpreter requests a 
printable representation of the variable 
from the server and then converts that to 
a double-precision value, which it stores in 
the child. (The double-precision values are 
used only by compiled code. The inter¬ 
preter continues to use the values stored on 
the exact machine.) Unfortunately, 
because exact values are computed in a 
demand-driven fashion, this “display” 
operation, which produces a printable rep¬ 
resentation, is the costliest of all exact 
operations. As described above, the exis¬ 
tence of interprocedural dataflow infor¬ 
mation will allow us to limit display 
operations to only those necessary because 
of actual references to the values in output 
statements or compiled code. 

To single-step the program counter in 
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Compiled code (executed in detached process) Interpreted code (executed in environment) 

call ISUB 



Figure 7. Control flow during call from compiled code to interpreted code. 


reverse, we need to keep track of all the 
states that the program enters. One way to 
achieve this is to make sure that each 
change to the program state can be 
undone. To reverse program execution, we 
need to be able to reverse each different 
kind of statement: 

• If successive values assigned to a var¬ 
iable are kept in a push-down store, 
then an assignment statement can be 
reversed by popping from the stack. 

• To reverse a branch, we need to keep 
track of where execution came from 
at all branch targets (both explicit and 
implicit). Again, this needs to be done 
in a last-in, first-out fashion. 

• Subroutine or function calls to com¬ 
piled code are similar to assignment 
statements except that, instead of sav¬ 
ing a single scalar value, we will need 
to save all variables that are poten¬ 
tially modified by the compiled code. 
In the absence of interprocedural 
dataflow information, this amounts 
to saving all parameters, static vari¬ 
ables, and globally accessible vari¬ 
ables (e.g., those in Common in a 
Fortran program). With the dataflow 
information in R n , however, we have 
a more precise description of what 
will need to be checkpointed. 


• I/O statements are perhaps the most 
difficult to handle efficiently. We can 
handle stream I/O fairly simply by 
keeping counts of how much input or 
output was performed by a state¬ 
ment. Nonstream output could be 
handled as an assignment statement 
on a very large array, although this 
has obvious efficiency problems on 
large files. 

Whole-program analysis 
and optimization 

Numerical programmers have long 
demanded that compilers produce effi¬ 
cient code. This is particularly true in the 
Fortran realm, where programmers have 
come to expect that their existing “dusty 
decks” will be translated, automatically, 
to take maximal advantage of new 
machines and new architectures. This atti¬ 
tude presents a major challenge to 
designers of optimizing compilers. Tech¬ 
niques in intraprocedural optimization 
have reached a fairly mature state. To fur¬ 
ther improve the efficiency of compiled 
code will require an optimizer that con¬ 
siders the whole program, planning 
optimizations based on program-wide 


information. This is a natural evolution¬ 
ary step in the development of optimizers, 
which have progressed from statement-by¬ 
statement code improvement, through 
techniques that handled sequences of 
statements, to global optimizations that 
take an entire subroutine into account. 

In R n we are building an inter¬ 
procedural optimizer that analyzes the 
entire program and plans optimization 
from a whole-program perspective. Con- 
radi has estimated that aggressively pursu¬ 
ing such an approach can result in a speed 
improvement of 20 percent or more. 4 

In the overview section we saw how the 
tools in R n cooperate to provide the infor¬ 
mation necessary to perform inter¬ 
procedural analysis and optimization. 
However, this introduces a new problem. 
Once the compiler uses interprocedural 
information as a basis for compile-time 
decisions, it introduces subtle and complex 
compilation dependences between the 
procedures in the program. To see this, 
consider two procedures a and b that are 
components of a single program. In com¬ 
piling a, the compiler applies optimiza¬ 
tions that it knows are safe, using 
interprocedural facts gathered from 
analyzing the whole program. If the user 
makes an editing change to b that adds 
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some fact to one of its interprocedural 
dataflow sets, and the previous compila¬ 
tion of a relied on the absence of the fact 
to justify the safety of some optimizing 
transformation, then the change retroac¬ 
tively makes that transformation unsafe. 
(Of course, the analogous case, in which 
a fact is deleted and the compiler relied on 
its presence in a previous compilation, 
requires similar treatment.) Thus, if the 
compiler uses interprocedural facts as a 
basis for compile-time decisions, it must 
have the ability to later retract the decision 
in response to editing changes that invali¬ 
date the correctness of the transformed 
program. 

In a traditional compiler the only way to 
achieve this is by compiling the whole pro¬ 
gram at once—an expensive proposition 
that removes the benefits of separate com¬ 
pilation. In the R" compilation system we 
track the compilation dependences intro¬ 
duced by the use of interprocedural infor¬ 
mation to limit the amount of analysis and 
compilation required to return the pro¬ 
gram to a state consistent with its source 
code. This “damage control” strategy 
allows the compilation system to retain 
some of the benefits of separate compila¬ 
tion while aggressively using inter¬ 
procedural information to improve the 
efficiency of compiled code. This 
approach should make the system practi¬ 
cal for large programs. 

To allow it to efficiently perform whole- 
program optimization, we divided the R" 
compiler into two parts: a program com¬ 
piler that handles the interprocedural 
aspects of the compilation process and a 
module compiler that performs 
intraprocedural optimization. The pro¬ 
gram compiler is responsible for building 
a consistent executable for a program, 
computing interprocedural information 
for use by the module compiler, and deter¬ 
mining which procedures should be 
recompiled. The program compiler also 
determines where interprocedural optimi¬ 
zations should be performed. The module 
compiler produces optimized object code 
for a single module based on information 
provided by the program compiler about 
the context program and its own analysis 
of the module source code. An artifact of 
this compilation strategy is that the code 
generated by the module compiler is a 
function of the program in which the mod¬ 
ule is incorporated as well as its own 
source. Hence, the object version cannot 
be safely reused in other programs. 

Program compiler. The program com- 



After the program 
compiler updates the 
interprocedural 
information for a 
program, it constructs 
procedures that 
require recompilation. 


piler is assigned the task of directing the 
compilation of a program and computing 
information about the program that other 
tools in the environment can use. Since the 
programs being compiled may be large, 
efficiency is a major concern. This is par¬ 
ticularly important when the program 
compiler is recompiling an existing pro¬ 
gram that has been slightly modified. To 
recompile such a program, it employs effi¬ 
cient algorithms for computing the inter¬ 
procedural information. (If possible, an 
incremental update is applied.) It next per¬ 
forms analysis aimed at limiting the num¬ 
ber of procedures that must be recompiled. 
Finally, it selects interprocedural optimi¬ 
zations for the module compiler to per¬ 
form on the procedures slated for 
recompilation. These three phases of pro¬ 
gram analysis and optimization are 
described in the following paragraphs. 

Interprocedural information. Before a 
program can be compiled, interprocedural 
information for the program must either 
be derived or updated. The program com¬ 
piler is the tool that actually computes this 
information, so its first task when compil¬ 
ing a program is to perform inter¬ 
procedural analysis on the program. It 
uses initial information provided by the 
module editor, the call graph components 
provided by the composition editor, and 
any interprocedural information for the 
program computed by previous compila¬ 
tions. It stores the results of its analysis in 
the database. Interprocedural summary 
sets, like the MOD sets described earlier, 
are one type of information it produces; 
interprocedural constants are another. 

An interprocedural constant is a vari¬ 
able that has a known constant value on all 
invocations of a procedure in a given pro¬ 
gram. The process of discovering inter¬ 
procedural constants and their values is 
known as interprocedural constant propa¬ 
gation. These constants may provide valu¬ 


able information about loop strides and 
bounds that can improve the compiler’s 
ability to optimize the whole program. 
This is often the case in large programs 
that call library routines. Unfortunately, 
the precise solution to the constant propa¬ 
gation problem, whether interprocedural 
or intraprocedural, is not computable. In 
fact, even the standard approximations 
solved intraprocedurally are co-NP com¬ 
plete in the presence of aliasing between 
call-by-reference formal parameters and 
global variables. 5 Fortunately, it is possi¬ 
ble to find approximate solutions to this 
problem, solutions that contain inter¬ 
procedural constants that are valuable for 
optimization. 

In R n we have developed a method for 
computing interprocedural constants in 
which the creation and transmission of 
constants within a procedure is modeled by 
a function constructed by the source edi¬ 
tor. 2 The interprocedural analysis phase 
invokes these functions at program com¬ 
pilation time to model the flow of con¬ 
stants between procedures. 

Recompilation. To make the R n compi¬ 
lation system practical for large programs, 
we have tried to retain some of the benefits 
of separate compilation. Recall that using 
interprocedural information as a basis for 
optimization introduces subtle compila¬ 
tion dependences between the procedures 
in a program. In R n the compiler analyzes 
these dependences to predict how source 
code changes can affect the correctness of 
previously compiled code. This informa¬ 
tion, in turn, allows the compiler to deter¬ 
mine which procedures must be 
recompiled to ensure consistency in the 
program after an editing change. 2 

After the program compiler updates the 
interprocedural information for a pro¬ 
gram, it constructs a list of the procedures 
requiring recompilation. It initializes the 
list to contain all those procedures that 
must be recompiled because of direct edit¬ 
ing changes. This list is actually produced 
by the two editors. If the initial list does not 
contain all the procedures in the program, 
the program compiler then examines each 
procedure in which interprocedural sets 
have changed to see if it must be recom¬ 
piled because of changes in its inter- 
procedural sets. 

All of our techniques for recompilation 
analysis apply the same test to determine 
when a procedure must be recompiled. 
The test compares the current inter¬ 
procedural information against annota¬ 
tion sets. These sets contain interproce- 
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dural facts that can be true without 
invalidating the procedure’s previous com¬ 
pilation. The various methods we have 
proposed differ in the precision with which 
they assign values to the annotation sets. 

Interprocedural optimization. The pro¬ 
gram compiler examines the whole pro¬ 
gram to develop a plan for applying 
interprocedural optimizations. Some parts 
of the plan are obvious. For example, any 
constants discovered during the inter¬ 
procedural analysis will be folded into the 
individual procedures where they hold. 
Other parts of the plan require explicit and 
complex decision processes, such as the 
decision on where to perform in-line sub¬ 
stitution. 

The approach we are pursuing is imple¬ 
mented in the program compiler. The pro¬ 
gram compiler constructs the call graph, 
gathers information about each proce¬ 
dure, and computes interprocedural 
dataflow information. Next, it evaluates 
and compares the possible transforma¬ 
tions, applying those with the largest esti¬ 
mated improvement. Finally, it invokes 
the module compiler on individual mod¬ 
ules, passing it directives to guide the 
optimization process. By comparatively 
evaluating the opportunities for applying 
these transformations, the program com¬ 
piler directs the effort of the module com¬ 
piler into the areas that are most likely to 
pay off from the perspective of the whole 
program. 

Module compiler. While the program 
compiler effectively directs the whole- 
program optimization by providing inter¬ 
procedural information and inter¬ 
procedural optimization directives, the 
module compiler actually implements 
these optimizations. It does this both 
indirectly, by using interprocedural infor¬ 
mation to improve the precision of its 
intraprocedural information, and directly, 
by applying the interprocedural transfor¬ 
mations as directed. 

The module compiler uses information 
about side effects of procedure calls to 
improve the precision of the intra-pro¬ 
cedural dataflow information around the 
call sites. The increased precision of the 
dataflow information leads to an improve¬ 
ment in the module compiler’s ability to 
optimize procedures. For instance, con¬ 
sider performing redundant subexpression 
elimination. To determine which expres¬ 
sions are eligible for redundant subexpres¬ 
sion elimination at a given point in a 
procedure, the compiler must compute 


which expressions are available. An avail¬ 
able expression is an expression that was 
computed and not subsequently changed 
along any path leading to the point of 
interest in the program. 

If, when computing the available 
expressions, the compiler encounters a 
procedure call, it is forced to make conser¬ 
vative assumptions about the side effects 
of invoking that procedure. In the absence 
of interprocedural side effect information, 
the compiler must assume that any vari¬ 
ables that were visible to the called proce¬ 
dure may have been changed by the 
procedure call. When any of these vari¬ 
ables appear in an expression that is con¬ 
sidered available before the procedure call, 
the expression must be marked as unavail¬ 
able because its value may have changed 
as a result of the procedure invocation. If 
interprocedural information is present, the 
compiler need only invalidate those 
expressions that rely on a variable con¬ 
tained in the MOD set for the call site. As 
a result, expressions containing only var¬ 
iables that cannot be modified are still 
available after the call. This leads to a 
larger set of available expressions and, 
potentially, allows additional redundant 
subexpressions to be eliminated. This 
improvement speeds up the resulting 
executable. 

The module compiler uses information 
about aliases between formal parameters 
and global variables to improve 
intraprocedural optimization. For exam¬ 
ple, in the absence of interprocedural alias¬ 
ing information, the compiler cannot 
determine whether or not pairs of global 
variables or formal parameters occupy dis¬ 
joint storage locations. To avoid incorrect 
code, the compiler cannot store such var¬ 
iables in registers. If the compiler knows 
that the aliases do not exist, it can store 
these variables in registers, with a result¬ 
ing improvement in the speed of the object 
code. Knowledge of aliasing patterns 
comes into play in nearly every optimiza¬ 
tion decision. 

Similarly, the module compiler uses 
information about interprocedural con¬ 
stants as input to its own intraprocedural 
constant propagation analysis. This allows 
the intraprocedural analyzer to recognize 
constants inherited from the calling envi¬ 
ronment. In practice, important informa¬ 
tion like array dimensions and loop strides 
are likely to be detected by the inter¬ 
procedural constant propagation; this 
information can play an important role in 
purely intraprocedural optimizations, 
such as loop unrolling. 


Information about interprocedural side 
effects not only helps produce better code, 
it can also reduce the amount of analysis 
required in the module compiler. Our 
experience with PFC shows that the num¬ 
ber of use-definition chains constructed by 
the compiler can be drastically reduced 
through the use of interprocedural analy¬ 
sis. This occurs because the compiler is 
able to use the interprocedural side effect 
information at a call site to determine 
which variables visible to the called proce¬ 
dure have been used or redefined as a result 
of invoking the procedure. The compiler 
then is not forced to make conservative 
assumptions about the side effects of the 
procedure call and create unnecessary use- 
definition chains. 


Support for parallel 
programming 

In the next phase of research we plan to 
evolve R n to support parallel program¬ 
ming, a natural extension of our work on 
automatic detection of parallelism and 
software for supercomputers. 6 Here, we 
begin with a summary of work to date on 
the supercomputer software project. Then 
we present a conceptual picture of the 
parallel-programming environment we 
envision, along with a discussion of imple¬ 
mentation strategy. 

PFC and PTOOL. Since 1978 a group 
at Rice has been conducting an active pro¬ 
gram of research in software for vector 
and parallel supercomputers. This 
research has led to two important experi¬ 
mental systems; PFC and PTOOL. 

PFC (Parallel Fortran Converter) is a 
system that automatically vectorizes For¬ 
tran programs by performing a sophisti¬ 
cated analysis of dependence. A 
dependence exists between two statements 
if one statement can store into a location 
that is later accessed by the second state¬ 
ment. Although most optimizing com¬ 
pilers analyze dependence in a program, 
they use a particularly naive treatment of 
arrays. Vectorization systems employ a 
much more powerful analysis that is fairly 
effective in dealing with subscripted refer¬ 
ences in loops. 7,8 

As an illustration of the analysis of 
dependence, consider the following code 
fragment (expressed in Fortran 8x 
notation): 

DO I = 1, N 
X(I) = Y(I) + C 
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Y(I +1) = X(I) + A(I) 

REPEAT 

The second statement depends on the first 
by virtue of the value stored in X(I) and 
then loaded on the same iteration. This 
dependence is called a loop-independent 
dependence because it forces a particular 
ordering among the statements in the body 
of the loop. The first statement depends 
upon the second one because of the value 
stored into Y(I + 1) on one iteration and 
loaded from Y(I) on the next one when I 
has been incremented. This dependence is 
said to be “carried” by the loop because 
it forces an ordering among the different 
iterations of that loop. To put it another 
way, the existence of a carried dependence 
prevents the separate iterations from being 
run completely in parallel unless some syn¬ 
chronization is inserted to ensure that the 
proper values of Y are used on each itera¬ 
tion. Such a synchronization effectively 
serializes the loop. 

Research on PFC has concentrated on 
finding vectorization algorithms efficient 
enough for use in a compiler. An indica¬ 
tion of its success is that PFC served as the 
prototype for the IBM VS Fortran Version 
2 vectorizing compiler for the 3090 Vector 
Feature, 9 which achieves excellent results 
while remaining reasonably efficient. (The 
IBM compiler, based on an early version 
of the PFC system, is quite effective at vec¬ 
torization and requires only a modest 
increase in compile time over the scalar VS 
Fortran compiler with optimization.) 

Since completion of the original PFC in 
1982, research has continued in three 
areas. First, algorithms to perform inter¬ 
procedural analysis on whole programs 
have been added. The approach used is 
based upon experimentation with an 
implementation of the algorithms devel¬ 
oped for R n . The aim of this work is to 
determine the impact of whole-program 
knowledge on vectorization and paralleli¬ 
zation. Currently, PFC analyzes side 
effects of procedure calls, aliasing pat¬ 
terns, and constants propagated across 
procedure boundaries. 

Second, we have been developing 
parallel-programming tools that use 
PFC’s analysis phase. Our first effort, 
called PTOOL, is an interactive adviser 
designed to assist in the prevention of 
errors arising from unintentional data 
sharing or unforeseen load-store orders 
for shared data in parallel programs. 
PTOOL is really a sophisticated browser 
for an interstatement-dependence data¬ 
base created by PFC. It permits the user to 
select a loop in a sequential Fortran pro- 
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This project has broken 
new ground in the use 
of components of a 
software development 
environment to 
support process. 


gram and ask whether or not the iterations 
may be run in parallel. If the answer is no, 
PTOOL will display all the carried depen¬ 
dences that would prevent parallelization. 

While PTOOL is extremely helpful for 
identifying loops that can be parallelized, 
it provides no assistance in the generation 
of parallel code. A third project is inves¬ 
tigating automatic generation of code for 
multiprocessors. This has led to another 
derivative of PFC, called PFC +, which 
not only recognizes loops whose iterations 
can be run in parallel but also performs 
sophisticated transformations, such as 
loop interchange, loop alignment, and 
code replication, to enhance the parallel¬ 
ism available. 7 

PFC now contains approximately 
95,000 lines of PL/I code and runs on an 
IBM 4341. PTOOL is already in use at Los 
Alamos National Laboratory and is sched¬ 
uled to be installed at Livermore and 
Argonne. Both PTOOL and PFC + will 
be installed at the Cornell Theory Center. 
These systems represent a significant 
research resource because they are rela¬ 
tively easy to modify. This makes it pos¬ 
sible to add and evaluate new 
transformation methods rapidly. In addi¬ 
tion, PTOOL has value as an educational 
tool—it is now used to teach compiler stu¬ 
dents about dependence in programs. 

A parallel-programming environment. 

Building on R n and our experience gained 
with PFC and PTOOL, we are enhancing 
R" with extensive support for parallel pro¬ 
gramming. This involves both continued 
work on the fundamental tools of the envi¬ 
ronment and the addition of entirely new 
features. 

The programming environment we 
envision will provide support for an 
extended version of Fortran that we call 
Parallel Fortran. This language will be 
similar to the emerging class of macro 
libraries that prpvide parallel¬ 


programming support in Fortran. Pro¬ 
gramming in the environment would take 
place in two phases. In the first phase the 
programmer would construct a correct 
program in a version of the language that 
has a single, nonparallel execution sched¬ 
ule. This is similar to writing the program 
in sequential Fortran. In the second phase 
the programmer would evolve the pro¬ 
gram into an efficient parallel program by 
eliminating dependences that prohibit a 
highly parallel schedule. 

It is in this second phase that the 
parallel-programming tools would be 
used. The environment will support a 
transformational style of programming in 
which the system provides automatic 
assistance. In this style the user asks the 
system where the performance bottlenecks 
are and can ask for suggestions or make a 
change. If the request is for suggestions, 
the system will reach into its library of 
transformations to find the ones that will 
improve the parallelism without changing 
the meaning from the fixed-schedule ver¬ 
sion of the program. The user can then 
select a transformation to be performed. 
If, on the other hand, the user makes a 
manual change, the system will attempt to 
prove that the change preserves the mean¬ 
ing of the fixed-schedule program. If it 
does not succeed, it then records the 
change as one to be tested later. 

To support this style of programming, 
we must make many changes to the exist¬ 
ing software. First, we must have ways of 
incrementally analyzing dependence and 
making transformations in the source edi¬ 
tor. Second, we must have ways of analyz¬ 
ing a program in enough depth to verify 
that a change preserves meaning. Finally, 
we must have ways to use information 
about questionable changes in the testing 
and debugging process. In addition, a 
good parallel-programming environment 
must include support for the design of par¬ 
allel programs. The following subsections 
discuss the ways we propose to address 
these requirements. 

Dependence analysis in a structure edi¬ 
tor. In the automatic detection of parallel¬ 
ism, the key analytical information used 
by a compiler is a dependence graph for 
the procedure. 7,8 Our experience with the 
PTOOL system has convinced us of the 
value of presenting dependence informa¬ 
tion to explain why particular loops will 
not run in parallel. Unfortunately, because 
PTOOL relies on a batch analysis of the 
program, users have been frustrated by the 
delay between typing a proposed change 
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into the source and getting feedback about 
its impact. To build a more responsive 
parallel-programming adviser, we plan to 
maintain a current dependence graph in 
the structure editor for Fortran, incremen¬ 
tally rebuilding dependences whenever the 
source is modified. In addition, we will 
provide automated support, for transfor¬ 
mations that increase the parallelism avail¬ 
able in a Fortran program. The resulting 
editor should make experimentation with 
parallel programming reasonably easy. 

Improvements of interprocedural anal¬ 
ysis. The analysis of interprocedural side 
effects is an important component of the 
system because accurate information 
about interprocedural dataflow is essential 
if we are to verify the manual transforma¬ 
tion steps discussed earlier. Our experience 
with interprocedural dataflow analysis in 
both R" and PFC has convinced us that 
improvements are needed in both the the¬ 
ory and the implementation. Two partic¬ 
ular problems present themselves: the need 
for more precise treatment of arrays and 
the need for incremental updating tech¬ 
niques. We intend to further our work on 
the theoretical front while at the same time 
pursuing implementations in the new 
parallel-programming environment. 

Our experience with using inter¬ 
procedural summary information in a 
working system for detecting parallelism 
has shown that the granularity of conven¬ 
tional summary information is too coarse 
to allow effective detection of parallelism 
in loops that contain call sites. The prob¬ 
lem is that the current analysis treats whole 
arrays as single units. Thus, it is able to 
determine whether an array is modified 
somewhere but not whether it is modified 
in only a single column or row. This limi¬ 
tation is disastrous for parallelization 
because the most effective way to paral¬ 
lelize a loop is through data decomposi¬ 
tion in which each parallel iteration works 
on a different subsection of a given array. 

Fortunately, a generalization of the 
approach currently used to solve inter¬ 
procedural dataflow analysis problems 
can be used to develop more precise infor¬ 
mation about side effects. The standard 
algorithms for interprocedural analysis 
can be extended in a natural way to deal 
with a lattice of regular sections of an 
array. Each regular section represents a 
common pattern of access to a subarray, 
such as a single element, a whole row, or 
a whole column. If the regular-section lat¬ 
tice is carefully designed, the analysis will 
produce information precise enough to do 


a good job of parallel decomposition with¬ 
out becoming unacceptably inefficient. 
Nevertheless, we expect that regular- 
section analysis will require substantially 
more computing resources than the cur¬ 
rent techniques. This will increase the 
desirability of incremental methods for 
updating interprocedural information in 
response to a program change. In address¬ 
ing this problem, it is important to evalu¬ 
ate the trade-off between incremental and 
parallel evaluation methods, since it seems 
likely that batch algorithms will be more 
amenable to parallel execution than 
incremental techniques. 

Parallel debugging. Currently, the R" 
execution monitor supports the debugging 
of a sequential program on the local 
machine. We plan to enhance it to support 
debugging of programs executing on 
remote machines and to support the 
management of parallel background 
processes, using an approach similar to 
those employed by the emerging class of 
parallel Unix debuggers, such as those 
offered by Sequent and Alliant for use 
with their machines. 

However, what may well be the most 
difficult problem in debugging code for 
shared-memory multiprocessors still 
remains: It is very hard to recreate with a 
debugger the sequence of events that led to 
an error of unintentional data sharing. To 
address this problem, we plan to use the 
information from the environment discov¬ 
ered during analysis and compilation to 
provide clues to the location of errors at 
run time. 

For example, if an incorrect value is 
detected in a parallel program at a point 
where the sequentially scheduled version 
produced the correct value, the debugging 
system would be invoked. It would trace 
back to locations inside parallel regions 
that might have contributed to the compu¬ 
tation of the erroneous value. Then, to 
help locate the problem, it would use 
adversary scheduling, a technique that 
employs dependence analysis to pick 
schedules likely to lead to errors. In other 
words, the debugger would step the 
processors in a sequence that static analy¬ 
sis suggests is likely to produce a different 
answer from the standard sequential 
schedule. 

Whole-program planning. In a system 
for automatically decomposing a large 
program for parallel execution, optimiz¬ 
ing transformations should be planned 
from a global perspective. For example, to 


make effective use of in-line substitution, 
the compiling system must plan the 
optimizing transformations, including 
parallelization, for the whole program. As 
outlined in the preceding section, planning 
optimizations on a whole-program basis is 
the responsibility of the program 
compiler. 

The planning phase of the program 
compiler is the natural place to identify 
larger-granularity parallelism. The pro¬ 
gram compiler will select the loops to be 
run in parallel, considering loop nests that 
span procedure call boundaries. It will use 
this information as input to its decision 
process for selecting procedure calls for in¬ 
line substitution. The program compiler 
will include this information in the direc¬ 
tives passed to the module compiler. Thus, 
the module compiler will know which rou¬ 
tines contain parallel loops and which ones 
will be run from inside parallel loops. 


T he R n project has broken new 
ground in the use of components 
of a software development envi¬ 
ronment to support the compilation pro¬ 
cess, while developing a number of new 
ways to build those component tools. The 
research has contributed new algorithms 
for interprocedural analysis and methods 
for managing the recompilation problem. 
It has also explored an approach to 
language-oriented editing that combines 
the advantages of text and structure edit¬ 
ing and a debugging system that permits 
the mixed execution of compiled and inter¬ 
preted routines. 

The current implementation, scheduled 
for distribution to a number of sites this 
fall, consists of approximately 105,000 
lines of C and runs on both the IBM RT 
PC and Sun workstations. Over the next 
several years the implementation will 
evolve as scientific programming evolves, 
with the principal change being the incor¬ 
poration of advanced features for the sup¬ 
port of parallel programming. □ 
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Confessions of a used-program salesman—the RISC versus CISC debate 


Just when things seemed to be going 
smoothly, a battle of epic proportions 
started brewing down at the used- 
program shop. I never thought we 
would have a RISC versus CISC debate 
related to used programs, but as I 
always say, “If the module has the right 
parameters, call it.” And that really 
was the crux of the problem. You see, 
my customers seemed to have gotten a 
bad case of the WIBNIs (the “Wouldn’t 
It Be Nice Ifs”*). My programmers, 
eager to please existing customers and 
attract new ones, started adding new 
parameters and options to existing soft¬ 
ware packages and building blocks. At 
first, this tactic gave the desired results: 
it increased each module’s domain of 
applicability, thereby increasing its 
reuse. But pretty soon the advantages of 
having all these options actually 
decreased a program’s reusability 
because customers grew unable to com¬ 
prehend the dependencies and interac¬ 
tions between the options. We had 
violated two of the Golden Rules of 
Reusability: (1) Before you can reuse 
something, you have to know what it 
does; and (2) before you can reuse 
something, you have to know how to 
reuse it. ** 

Furthermore, the customers were 
concerned about dragging around all 
the extra code for the options they 
didn’t use, thus paying for the addi¬ 
tional size and function they didn’t 
want or need. More importantly, I real¬ 
ized that these multifaceted, monolithic 
modules were becoming harder to docu¬ 
ment and maintain. 

This is how the great RISC (Reduced 
Interface Software Component) versus 
CISC (Complex Interface Software 
Component) debate began. Should soft¬ 
ware subroutines have complex or sim¬ 
ple interfaces? The CISC proponents 
wanted to throw everything, including 
the kitchen sink, through the one inter¬ 
face, arguing that with intelligent 


*1 first encountered this term in Peter Brown’s 
Starting with Unix (Addison-Wesley Publishing 
Company, 1984). 

•The first Golden Rule of Reusability is “Before 
you can reuse something, you have to find it.” 


defaults their interfaces were as simple 
to use as the RISC interfaces. The RISC 
side pointed out that the overhead from 
dragging all the extra logic to handle the 
bells and whistles (which were seldom 
used anyway) was a needless penalty for 
the most frequently used operations. 
They argued that the CISC format 
could be replaced by a series of RISC 
operations. The CISC camp countered 
by pointing out that to achieve the same 
power as a CISC operation, a RISC 
implementation would result in more 
context switches (notorious cycle 
burners). They observed that, although 
their operations were slightly slower 
than the RISC subroutines, they could 
do more at once because they had more 
opportunities for parallelism. The RISC 
side countered that their interface 
allowed the same parallelism with more 
flexibility and better user control. The 
CISC side scored their biggest points 
when they argued that the RISC 
approach would fail in a multitasking 
situation, where multiple threads of 
control could adversely affect each 
other through side effects. 

Somehow, as I watched this debate, I 
had the feeling of deja vu. Personally, I 
was most interested in the bottom 
line—what made dollars and sense. I 
preferred reducing the number of inter¬ 
faces because there would be less con¬ 
figuration management, and I knew 
that current optimization technology 
could take care of the dead code 
problem. 

The conclusion that I came to was 
that both camps had some valuable 
points to make. The RISC people were 
right that the CISC people were not 
exercising caution in their application 
of “tail-fin” technology. Instead of 
increasing the domain of applicability, 
we were approaching the domain of 
absurdity. The CISC people were right 
in trying to provide additional function, 
but they had missed the opportunity to 
practice what they preach (modulariza¬ 
tion). One of the fundamental underly¬ 
ing software principles of reusable 
software development is factoring: 
developing a hierarchy of reusable com¬ 
ponents (each capable of performing a 
single function) and combining these 
reusable components through inher¬ 


itance, instantiation, or simple impor¬ 
tation. Factoring breaks a monolithic 
module into pieces. This practice helps 
the programmer to compose and main¬ 
tain a better user interface by hiding the 
actual implementation one layer down. 

We learn by our mistakes, but I wish 
we didn’t have to relearn things so 
often. 

Sincerely, 

Will Tracz (your friendly 
used-program salesman) 

Computer Systems Laboratory 
Stanford University 


The fertile crescent 

A man I know was recently criticized 
by one of his managers for not giving 
“nice synthesized answers” to ques¬ 
tions. Perhaps we have all known some¬ 
one who, when asked what time it was, 
told us instead how to build a clock. 
Conventional wisdom holds that being 
evasive or verbose is at least a bad habit 
and at worst a substitute for intelligent, 
hard work. However, questions are not 
always simple. 

Consider the accompanying grid, 
which illustrates the diverse research 
endeavors of the computer industry. In 
the lower left quadrant, we find 
research being conducted on the least 
mature technology and the fuzziest 
questions. In the upper left quadrant, 
we find mature technology being used 
to work on fuzzy problems (for exam¬ 
ple, Cray computers being programmed 
with Fortran to solve Navier-Stokes 
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equations in search of revolutionary 
new aircraft wing and engine designs). 
In the lower right quadrant, we find 
unproven technology being used for the 
solutions to well-formulated, but as yet 
unanswered questions (for example, a 
massively parallel machine and a self¬ 
modifying rule-based system being used 
to play chess). And in the upper right 
quadrant, we find mature technology 
being applied to finding solutions to 
well-understood, albeit important 
problems. 

I will conjecture that 90 percent of 
the computing resources in America are 
employed in the mainstream—using 
mature technology to solve well- 
formulated problems (for example, con¬ 
sider IBM’s products and users and 
consider that many other companies do 
not enjoy either the breadth or the 
depth of IBM, which probably covers 
this entire grid rather well but earns 
most in the mainstream). 

I will further conjecture that over 
half of today’s mainstream products 
and applications came from the “fertile 
crescent” work of the prior decade (for 
example, consider the birth of the PC, 
the practical applications of AI, the 
growth of networks that work, the 
advances in supercomputing, and the 
decline of electronic accounting 
machines and batch processing). 

I will venture that this evolutionary 
trend will continue and that at least half 
of the mainstream products and appli¬ 
cations of the next decade will be based 
on now unfamiliar technology, on ques¬ 
tions that are still fuzzy, or on ideas 
that aren’t even being actively pursued 
yet. 

An honest and intelligent scientist 
will resist giving “nice synthesized 
answers” to questions involving imma¬ 
ture technology or undefined issues. 

One can discuss questions candidly and 
succinctly without being simplistic; few 
significant problems can be reduced to 
one page, and almost none to a simple 
“yes” or “no.” The gift of accurate 
summary is rare: Eric Sevareid did it in 
news analysis; Jerry Saltzer does it in 
computer science lectures. They have 
few peers. 

Research and development in most 
fields is characterized historically as 
demanding a high tolerance for 
ambiguity. Computing is no exception. 

1 hope that managers in the main¬ 
stream will be tolerant of those in the 
“fertile crescent.” Otherwise, we risk 
reducing exploratory work to an unac¬ 
ceptable level. Back home, farmers call 
that “eating the seed corn.” 

Bob Estell 

Naval Weapons Center 



Gentle ocean breezes, breathtaking sunsets, and 
the most exotic software projects you can imagine. 

That’s what awaits qualified software engineers at 
Lockheed Missiles & Space Company in Sunnyvale. 

We offer you a software paradise full of rare 
challenges and opportunities. Along with access 
to advanced computer systems, such as APOLLO, 
SYMBOLICS, VAX AND CDC CYBERS. Experienced 
software engineers are invited to explore the 
following career paths: 

Software Requirements Analysis, Design and 
ADA Code Development 

• Five or more years’software engineering experience 

• ADA design and code development experience 
is preferred. 

Simulation and Real-Time Code Design 

• Experience with VAX/VMS, FORTRAN and PDP 
11/70 Assembly Language is required. 

Real Time and Operating Systems Development 

• Eight or more years’ software engineering 
experience 

• Knowledge of FORTRAN and VAX/VMS is required 
FORTRAN Software Development 

• Four or more years’ experience in a VAX/VMS 
environment 

• Experience in real-time modeling, VMS Systems 
Management, FMS/Datatrieve, Database Man¬ 
agement or graphics software is preferred. 
Experience with high-priority defense programs 

is strongly desired. 

Take a walk on the wild side. Send your resume 
to Professional Staffing, Dept. 530HRLB, Lockheed 
Missiles & Space Company, EO. Box 3504, Sunnyvale, 
CA 94088-3504. We are an equal opportunity, affirm- 
' >n employer. U.S. citizenship is required. 
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Editor: Helen M. Vtood, National Bureau of Standards, B154 Technology, Gaithersburg, MD 20899; (301) 975-3240. 

Standards for banking communication systems 

Donald A. Sheppard 

Chairman, Canadian Advisory Committee on Open Systems 


As communication technology has 
evolved, communication systems have 
become vital to the provision of finan¬ 
cial services. Current communication 
technology offers the potential for high- 
capacity, high-quality, global financial 
networking. Many bankers, however, 
are not prepared to exploit this poten¬ 
tial. Their lack of preparation is evident 
in their failure to participate in infor¬ 
mation technology standardization. 

This article assesses the state of current 
banking industry standards and argues 
for a stronger emphasis on a concerted 
approach to future standardization. 

Is there really a problem? Most 
bankers will readily accept that the 
infrastructure of banking is changing 
dramatically, leading to business 
requirements that depend on computer 
systems more than ever before. A bank 
is no longer a loosely coupled federa¬ 
tion of independent “micro-banks” 
(called branches) that serve a well- 
known but restricted community; a 
bank is now a vast storehouse of finan¬ 
cial information that can be accessed at 
a variety of business service access 
points —entry points which serve as the 
points of initiation for banking transac¬ 
tions (deposits, loans, transfers, infor¬ 
mation requests, and so on). Moreover, 
the traditional deposit, loan, and 
payment-processing functions of banks 
are evolving to encompass a wide vari¬ 
ety of interrelated financial services that 
span the four “pillars” of the economy: 


banking, insurance, securities, and 
trust. 

Banking has become a global finan¬ 
cial information management and con¬ 
trol industry that operates on a 24-hour- 
per-day, 7-day-per-week basis. The 
degree of customer convenience, defined 
in terms of availability, accessibility, 
and flexibility, is often a major distin¬ 
guishing feature among banks. Bank 
customers are becoming more sophisti¬ 
cated and more likely to demand immedi¬ 
ate access to information (such as 
interest or exchange rates) and prompt 
service (such as verification of a bill 
payment). Increasingly, customers want 
service to be available anywhere in the 
world. In response to these demands, 
banks are converting from batch-oriented 
accounting systems (which were the 
computer equivalent to manual opera¬ 
tions) to real-time, on-line, transaction¬ 
processing systems with intelligent, 
specialized workstations connected via 
high-speed networks. 

The first phase of banking systems 
implementation was completed in the 
mid-70s. This phase revealed that for 
each bank to provide effective acquisi¬ 
tion, processing, storage, and distribu¬ 
tion of financial information is a complex 
and costly process. In fact, some serv¬ 
ices, such as check processing, cannot 
be handled by each bank individually. 
These considerations have contributed 
to the rise in the number of shared 
banking networks. At the same time, 
the existence of different banking net¬ 


works has posed difficulties for the 
design of generic application software 
for banking. Such difficulties will com¬ 
pound as banks initiate new services, 
upgrade their technology, and expand 
the reach of their networks. 

Bankers must take an interest in any 
technology that promises to improve 
the effectiveness of banking operations, 
especially if the technology promises 
reduced costs, increased profitability, 
or new business opportunities. At the 
same time, bankers must weigh the risks 
and rewards of implementing these new 
technologies. Generally, they should 
opt for a cautious and evolutionary 
approach—after all, money that is 
stored electronically must be kept just 
as safe as dollars stored in a safe! 
Unfortunately, conservatism is some¬ 
times used as an excuse to avoid invest¬ 
ing time and resources in the research 
and planning stages of technology 
development. Participation in technical 
standardization should be viewed as a 
unique opportunity to influence 
manufacturers in a cooperative manner. 
Standards can establish a framework 
for and the basic functions of banking 
communications without eliminating 
the potential for competitive and 
innovative products. 

A scenario for advanced banking net¬ 
works. Banking networks are currently 
responding to an increased customer 
demand for point-of-service banking: 
banking which combines point-of-sale 
banking, home banking, corporate 
banking, and payments initiation 
mechanisms such as Electronic Data 
Interchange (EDI). This demand is a 
challenge for banking systems developers, 
since no existing system or network has 
proven that it can adequately support a 
mature electronic funds transfer (EFT) 
environment for point-of-service bank¬ 
ing. Projections show a need for an 
EFT environment that can interconnect 
millions of devices of a wide range of 
types, makes, and vintages, spread over 
a wide geographic area. Figure 1 illus¬ 
trates a future EFT environment as it is 
envisioned by banking systems 
developers. 


The ballot box 

So far, voting has been very close on the Point/Counterpoint debate that 
appeared in our September issue. Fifty-one readers have indicated that they sup¬ 
port the continued use of the IEEE Trial-Use Standard. Forty-five have indi¬ 
cated that they oppose the use of the IEEE Trial-Use Standard. Eleven have 
indicated that they are neutral or undecided. 

For an additional perspective on this debate, see Letters to the Editor, page 9. 
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In this EFT environment, banks in 
each country will be interconnected by 
national exchange networks. Each bank 
will probably own and operate its own 
access networks, which may, of course, 
be physically or logically integrated. 
Branch and public access networks are 
now well established and have success¬ 
fully implemented many technologies. 
Home and office access networks are 
still in their infancy, although trial sys¬ 
tems have been implemented and are 
expected to grow rapidly over the next 
decade. 

In this future environment, a cus¬ 
tomer at a public automated teller 
machine linked to bank A will be able 
request a transfer of funds to pay a bill 
to a company that also deals with bank 
A . The transaction will be performed by 
an in-house database transfer. If the 
company deals only with bank B, then 
the transaction will be more compli¬ 
cated, possibly involving a currency 
conversion combined with a transfer 
through the national and global 
exchange systems. A general bill pay¬ 
ment service of this nature is not usually 
available today unless the company 
maintains an account in each of the 
banks that accept payments on its 
behalf. 

If the network shown in Figure 1 is 
enlarged to include “one stop shop¬ 
ping” financial services access, or if 


banks expand to become full-fledged 
information brokers, then bank net¬ 
works will become extremely large 
indeed. A viable “wired world of bank¬ 
ing” will require significant sharing 
among banks and the ability to inter¬ 
connect many different applications 
technologies and networks in a very 
dynamic, robust, and secure manner. 
This environment will be economically 
impossible without commonly accepted 
standards such as those being developed 
under the umbrella of Open Systems 
Interconnection (OSI). 

Traditional standardization in bank¬ 
ing. Bankers are no strangers to stan¬ 
dards development. There have long 
been standards, even in a paper-based 
banking world, to ensure common 
understanding of the meaning of terms 
and the purpose of actions. One obvi¬ 
ous example of banking standards is the 
provision of currency designators. If 
international funds transfers are to be 
reliable, the currency of different coun¬ 
tries must always be distinguishable. 
What would happen if a Telex payment 
message did not provide a means to 
identify unequivocally between the 
Canadian dollar and the American dol¬ 
lar? Another example is the need for 
standards for the dimensions and cod¬ 
ing of credit cards. What would happen 
if the physical dimensions of credit 


cards were different for each bank in 
each country or if the contacts for inte¬ 
grated circuit cards were located in 
different places on different cards? 

How many people would have the same 
credit card number if a standard num¬ 
bering scheme did not exist? 

The processing of checks has been 
greatly facilitated by standardizing 
machine-readable encoding for account 
and amount information. This stan¬ 
dardization makes automatic sorting 
possible. In Canada, all checks are 
returned to the branch of account over¬ 
night; this would not be feasible with¬ 
out automatic routing and an advanced 
payment processing system. 

The EDI movement is currently 
attempting to eliminate paper invoices, 
receipts, and such from purchasing or 
trade activities. A reliance on paper 
(with signatures) has been the legacy of 
a paper-based checking environment, a 
legacy that has not yet been fully 
overcome. 

The de facto standards that were 
developed for use in the international 
interbank network called SWIFT (Soci¬ 
ety for Worldwide Interbank Financial 
Telecommunications) are typical of the 
types of standards that must be devel¬ 
oped in the future. The SWIFT network, 
which is a cooperative venture of its 
member banks, is notable both for its 
large store-and-forward communica- 
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Figure 1. EFT banking network environment. 
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tions system (using SWIFT specified 
protocols) and for its well-defined inter¬ 
bank messages. SWIFT currently serves 
some 1300 banks in 60 countries and 
processes over 700,000 messages each 
day, representing many millions of dol¬ 
lars. In the EFT banking environment 
shown in Figure 1, SWIFT would be 
classed as a combination of global and 
national exchange networks. SWIFT’s 
success derives from the fact that its 
members have agreed upon both the 
protocols to be used for the application 
messages and the communication serv¬ 
ices that it provides. 

TC68 and the standardization of 
banking communications. Currently, 
the banking community develops for¬ 
mal standards through Technical Com¬ 
mittee 68 (TC68) of the International 
Standards Organization (ISO), in con¬ 
junction with corresponding national 
standards committees, such as ANSI X9 
in the USA and the Canadian Advisory 
Committee to TC68 in Canada. The 
organization of TC68 is summarized in 
Figure 2. 

So far, TC68 has not been particu¬ 
larly attentive to the need for technical 
standards which could integrate bank¬ 
ing communications systems into an 
effective EFT environment. TC68’s 
activities have been principally focused 
on security, terminology and data ele¬ 
ment definition, and integrated circuit 
cards. 


Other ISO technical committees have 
produced at least three levels of standards: 

• reference models which develop a 
broad framework for an area of 
standardization, 

• specific standards that define in 
detail an individual facility or capa¬ 
bility, and 

• functional profiles which select 
options or classes of operation 
from the specific standards. 

In contrast, TC68 has concentrated 
primarily on specific standards and has 
not provided implementation guidance. 
This emphasis is beginning to change 
with work items such as the Integrated 
Circuit Card Security Architecture of 
SC6/WG7. But so far TC68 has not 
included systems issues in its standardi¬ 
zation activities. This is unfortunate, 
since the development of an effective 
EFT environment requires a broad 
framework and cooperation with other 
standards-producing groups. Mean¬ 
while, TC97 (the ISO committee 
responsible for information processing 
systems standards) has done work, 
especially with respect to abstract and 
transfer syntaxes, which has become 
increasingly pertinent to banking insti¬ 
tutions. 

Unfortunately, in the past there has 
been little payback or incentive for 
bringing national banking systems work 
to the attention of TC68. As a result, 
the majority of banks do not make sub¬ 


stantial or effective use of TC68. Exam¬ 
ples of this disregard include the 
following: 

(1) SWIFT II has been designed to 
upgrade the facilities of the existing 
SWIFT network and to integrate newer 
technology which will allow for growth 
over the next decade. SWIFT II uses 
some OSI protocols (primarily the 
lower four layers). However, no 
attempt has been made to turn the 
SWIFT II interface into a formal OSI 
“functional profile.” Additionally, 
nothing is currently being done to uti¬ 
lize the Message Handling Services stan¬ 
dards (CCITT X.400). 

(2) In the Netherlands, the Bank Giro 
Centrale has implemented the Data 
Communications Infrastructure (DCI) 
System for urgent interbank payments 
in Holland. DCI is based on OSI pro¬ 
tocols up to and including the Session 
Layer. None of this work has yet been 
submitted to ISO TC68 for consider¬ 
ation in its development of funds trans¬ 
fer standards. 

(3) In France, the Systeme Interban- 
caire de Telecommunication (SIT) is 
being developed for funds transfer of 
items other than checks, interconnect¬ 
ing approximately 700 banks. Also in 
France, the Banque Nationale de Paris 
has selected OSI standards for use in its 
“New Technical Architecture.” Their 
ultimate objective is to achieve a unique 
network complying with ISO standards 
based on Honeywell Bull products. 


TC68, Banking and related financial services 


-— WG2 Vocabulary and data elements 

I 

-— SC2 Operations and procedures 

I—-WG2 Message authentication 

—«■— SC4 Securities 

WG2 Securities message content 
WG4 Certificate numbers and optical scanning 

-- SC5 Information Interchange 

-— WG2 Telex messages 

— -— WG3 Bank telecommunications messages 

— -— WG4 Applications of OSI in banking 

-WG6 Paper documents 

-SC6 Financial transaction cards, related media, and operations 

-— WG1 Card-originated communications 

— -— WG3 Data content for track 3 

——-—— WG5 Messages between the integrated circuit card and the card acceptor device, and 

financial applications 

—-WG6 PIN management and security 

— -— WG7 Security architecture of banking systems using integrated circuit cards 


Figure 2. The organization of TC68. 


94 


COMPUTER 























Again, TC68 must be encouraged to 
coordinate developments such as these 
on a worldwide basis. 

TC68 must improve its procedures so 
that it can act in a forward-looking and 
responsive manner (as TC97 has done). 
It must consult the banking community, 
prioritize the specific work items that 
are most needed, and initiate an aggres¬ 
sive program of work. This program 
should include close collaboration with 
TC97 to ensure that TC97’s activities 
take into consideration the needs of the 
banking industry. The program should 
also stress the need to make banking 
communications standards compatible 
with OSI. 

Why use OSI-based standards in 
banking? Over the past year, OSI has 
been designated a significant role in 
many communication system products. 
OSI standards will be used, either 
explicitly or implicitly, by most major 
manufacturers and carriers. For instance, 
DEC has announced its intention to 
migrate its Digital Network Architec¬ 
ture to OSI standards; hence, anyone 
using DECnet will actually be using 
OSI. A significant number of OSI- 
compatible products have been intro¬ 
duced already, and many more are 
expected shortly. 

Banks can gain a business advantage 
by defining specific Application Layer 
standards using OSI tools and tech¬ 
niques and by using OSI protocols. The 
benefits of such an effort include the 
following: 

• OSI can be the foundation for 
powerful cooperative and distributed 
processing that can lead to new business 
possibilities for banks. OSI-integrated 
banks could possibly act as repositories 
for billing information (such as tele¬ 
phone bill details); provide a “single 
system image” for the banking, insur¬ 
ance, securities, and trust industries; 
and act as security administrators (via 
bank-supplied integrated circuit cards) 
for nonbanking applications. 

• OSI provides advanced function 
communications, including many fea¬ 
tures that could help to improve quality 
of service. OSI technology could enable 
worldwide interconnection of mail serv¬ 
ices, global directories, multivendor 
transaction processing, and integrated 
distributed system management. 

• OSI is likely to be accompanied by 
cost reductions. These will result from 
an integrated multivendor environment, 
fewer gateways and less custom soft¬ 
ware, worldwide acceptability of 
products, investment protection 
through the public nature of the stan¬ 
dards, and common testing services. 


Banks will probably benefit from 
these advantages whether or not they 
actively promote banking standards for 
use in an OSI environment. However, 
the use of OSI standards across various 
types of equipment should also help to 
reduce development, operation, train¬ 
ing, and support costs. 


The challenge for bankers. The chal¬ 
lenge for the banking community is to 
develop an effective EFT environment. 
To do so, the bankers must support the 
standardization effort and the use of 
OSI tools and techniques. 

The banking world needs an OSI 
champion to focus on Banking Auto- 


Standards briefs 

A Standard Dbase syntax document. 

The Draft Two Syntax Document of the 
Dbase Standards Working Committee is 
available to the public for comment. 

The draft document concerns the pro¬ 
posed Standard Dbase, a generic lan¬ 
guage that will deviate as little as 
possible from the language in Ashton¬ 
Tate’s dBASE III Plus and will allow 
for both interactive and noninteractive 
implementations. Interested parties 
should contact Sharon Davidson, Direc¬ 
tor of Operations at WallSoft Systems, 
Inc., 233 Broadway, Suite 869, New 
York, NY 10279. 

A draft standard for a Database Lan¬ 
guage SQL enhancement feature. 

Accredited Standards Committee X3 on 
Information Processing Systems has 
announced a four-month public review 
and comment period on the draft pro- 


mation Protocols, much as General 
Motors has done for the Manufacturing 
Automation Protocols and Boeing 
Computer Services has done for the 
Technical and Office Protocols. Mem¬ 
bers of the banking community can 
start by providing strong support for 
the methodology being created in 
TC68/SC5/WG4. Such support would 
be a tentative step in the right direction. 
Procurement preference policies, simi¬ 
lar to those of the US and UK Govern¬ 
ments (the GOSIP specifications), 
would be a much stronger commitment. 

Only when effective standards have 
been designed and implemented will the 
“wired world of banking” become a 
reality. 


posed American National Standard 
X3.135.1-198x. This draft standard is 
an addendum for Database Language 
SQL (ANSI X3.135-1986), approved as 
an American National Standard in 
1986. The draft standard develops addi¬ 
tional statements or clauses in Database 
Language SQL to specify an “integrity 
enhancement feature” that includes 
referential constraints between tables 
(without cascade effects), check con¬ 
straints to be applied to rows of a table, 
and a default value for a column when 
a row is inserted into a table. 

The draft standard is available for 
public review and comment from Sep¬ 
tember 11, 1987 to January 11, 1988. 
Copies may be obtained from Global 
Engineering Documents, Inc. by calling 
(800) 854-7179. Single copy price: 
$25.00. International orders: $32.50. 
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Arbitrators resolve compatibles copyright feud, order Fujitsu to pay IBM 


Two neutral arbitrators have issued a 
profound order resolving a long-standing 
software-copyright dispute between 
IBM and Fujitsu, the respective No. 1 
and No. 4 leading computer firms in the 
world. 

Under the order, Fujitsu will pay 
IBM an as-yet-undetermined compensa¬ 
tion fee for past and future use of IBM 
programs but will be permitted to con¬ 
tinue manufacturing mainframes com¬ 
patible with the those of the American 
firm. 

The order establishes a five-to-10 
year transition period during which the 
Japanese company will have access to 
IBM programming information through 
a tightly controlled procedure designed 
to protect IBM’s property rights. 

The arbitrators, Robert FI. Mnookin, 
a Stanford Law School professor, and 
John L. Jones, a retired executive vice 
president of Norfolk Southern Corp. 
with expertise in computer systems, told 
a New York City news conference Sep¬ 
tember 15 that they believe the order 
will benefit both companies as well as 
their customers. 

“The order allows Fujitsu to con¬ 
tinue to serve its customers and compete 
effectively, and allows IBM to protect 
its investment in research and develop¬ 
ment,” Mnookin said. Jones indicated 
he and Mnookin “made no determina¬ 
tion of fault or blame,” and added that 
the order “frees both companies from 
past uncertainties regarding intellectual 
property.” 

The dispute involved operating sys¬ 
tem software, the programs that man¬ 
age the internal functions of a computer 
and provide the features programmers 
use in designing applications. 

The mediators, representing the 
American Arbitration Assn., said they 
felt the order gave Fujitsu a reasonable 
opportunity to derive the information it 
needs to independently develop and 
maintain IBM-compatible operating 
systems. 

The order will also give customers 
more options, according to Mnookin 
and Jones. In the past, Fujitsu only 
licensed its operating system software to 


run on Fujitsu hardware. The arbitra¬ 
tors’ order gave users of each com¬ 
pany’s mainframes the right to license 
the other company’s software products 
in countries where those products are 
offered. As a result, customers may, for 
the first time, license Fujitsu operating 
system software to run IBM machines. 

The mediation process was initiated 
in 1985 after IBM alleged Fujitsu vio¬ 
lated its copyrights of operating systems 
for mainframes. In turn, Fujitsu held 
that it had only used IBM information 
that was unprotected under copyright 
law and was acting within the guidelines 
of agreements the companies struck in 
1983. It was stated that those agree¬ 
ments did not adequately resolve dis¬ 
putes concerning Fujitsu’s’s use of IBM 
information in developing Fujitsu oper¬ 
ating system software. 

The companies mutually agreed to 
have the dispute settled by the arbitra- 


Desktop PCs may soon literally oper¬ 
ate at the speed of light because a 
research team has developed a way to 
make lasers run on top of conventional 
computer chips. 

The chips, loaded with semiconduc¬ 
tors lasers, generate light to transmit 
data. This makes them potentially much 
faster and more efficient than conven¬ 
tional silicon chips, which transmit elec¬ 
trical impulses through wires. 

The University of Illinois develop¬ 
ment is a method of growing semicon¬ 
ductor lasers made of gallium arsenide 
and aluminum gallium arsenide—in a 
form known as a quantum well laser— 
on silicon. The resulting semiconductor 
component can be made to emit con¬ 
tinuous laser light at room temperatures. 

Nick Holonyak Jr., a professor at the 
university and one of the method’s 
developers, was one of the first to 


tors and are now bound by law to 
adhere to the Mnookin/Jones decision. 

The arbitrators will be determining 
the amount of the lump sum and will 
also set the actual length of the transi¬ 
tion period in the coming year. During 
that time, Fujitsu personnel will be per¬ 
mitted to obtain specific IBM informa¬ 
tion it will be able to use with immunity 
to develop software. Elaborate safeguards 
and strict supervision will be employed 
by an independent expert under the con¬ 
trol of the arbitrators. 

IBM was given a reciprocal right 
under the order; if it wishes, it may 
examine Fujitsu’s programs for its own 
software development. 

After the transition period, Fujitsu 
will only have access to the same IBM 
programming materials generally avail¬ 
able to customers and will be required 
to follow the copyright laws that apply 
at that time. 


demonstrate semiconductor lasers a 
quarter of a century ago when he led a 
research group at GE. 

He and his Illinois colleagues have 
now found a way to 'combine what he 
calls the apples and oranges of semicon¬ 
ductors: cheap, plentiful and rugged 
silicon, which is limited in speed and 
won’t generate light; plus expensive 
fragile gallium arsenide, which emits 
laser light when excited. 

“I could add a thousand lasers and 
have (them) all sending out signals at 
once to another computer on streams of 
photons,” Holonyak said. “We’ve 
taken the first step in being able to put 
high-grade optoelectronics on top of 
more conventional electronic chips.” 

The research was sponsored by the 
US Army Research Office and the 
National Science Foundation. 


Research leads to key discovery in 
semiconductor laser science 
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Intellectual ‘superhighway system’ foreseen developing across the US 


A linking of scientific minds that is 
historically unprecedented and largely 
unheralded is rapidly taking place in the 
United States, and its ultimate impact 
on scientific progress will be profound. 

Over the next few years, the explosive 
growth of a national high-speed com¬ 
puter network linking universities and 
industries will enable thousands of 
researchers nationwide to conduct 
research and collaborate with one 
another over long distances. Experts say 
that, by the end of the century, some 
one million scientists could be linked by 
the new system, the first such all- 
inclusive scientific network in history. 

When the system is complete, 
researchers all over the country will be 
able to use terminals and microcom¬ 
puters in their home laboratories to 
access supercomputers, to monitor their 
experiments on distant huge research 
machines such as particle accelerators, 
and to send and receive massive volumes 
of data, whole books and high- 
resolution graphic animation in a mat¬ 
ter of seconds. 

The foundation for this new high¬ 
speed intellectual “superhighway sys¬ 
tem” is being laid in the form of an 
intercontinental backbone network 
called NSFnet, linking supercomputer 
centers across the country. They’re 
located at Cornell University, the John 
von Neumann Center in Princeton, N.J., 
the National Center for Atmospheric 
Research, the University of California 
at San Diego, the University of Illinois, 
and the University of Pittsburgh/Carnegie 
Mellon University. 

Researchers on scores of campuses 
are already using the new network as a 
key communications link in their 
research. 

“This is where the action is,” said 
Stephen Wolff, director of the National 
Science Foundation division responsible 
for NSFnet. “World-class science is 
going on over the network; the people 
using it are the finest researchers in the 
nation in their disciplines, and they are 
able to do what they are doing because 
the network is there.” 

Over the next few years, this NSFnet 
backbone will blossom into a truly 
nationwide network as university cam¬ 
puses and industries install internal 
high-speed networks, as these individual 
networks, in turn, join regional networks 
and, finally, as the regional networks 
attach to NSFnet. With NSFnets the 
catalyst, other government-sponsored 
networks will also link up, creating an 
even more all-inclusive communications 
web. 


“It has become apparent to almost 
everyone during the past year that an 
interagency internet is inexorably upon 
us,” said Wolff. “The NASA Science 
Internet, Dept, of Energy’s Energy 
Sciences Network, NSFnet, and the 
ARPAnet will form an extremely large 
internet in support of scientific research, 
and few even question this idea that 
only a year ago seemed hopelessly 
visionary to many people.” 

Thus far, some 60 campuses have 
access to the network, a number which 


Despite the initial failure of a mea¬ 
sure that would extend California con¬ 
stitutional guarantees to intrastate 
electronic communication, the amend¬ 
ment’s author said she will make a new 
attempt to get the measure on the 
state’s election ballot. 

The measure, ACA 36, was defeated 
in the Assembly Elections, Reappor¬ 
tionment and Constitutional Amend¬ 
ments Committee (AERCA) in August, 
4-3. But the author, Assemblywoman 
Gwen Moore (D-49), has indicated that 
she plans to reintroduce what she calls 
the Information Age Bill of Rights mea¬ 
sure in January 1988. 

The bill had previously won approval 
from the Assembly Committee on Utili¬ 
ties and Commerce, 10-0. It would have 
gone before the full Lower House had it 
passed the AERCA, and probably would 
have been been placed on the California 


The latest advances in science, art, 
and education are incorporated into an 
exhibition that will be on display at the 
Museum of Science and Industry in 
Chicago through February 10, 1988. 

The exhibit, called “The Interactive 
Image,” was designed at the University 
of Illinois at Chicago and began in 
October. 

Featuring state-of-the-art computer 
technology and graphics, the exhibition 
is described as a unique learning envi¬ 
ronment that comprises powerful soft¬ 
ware programs and sophisticated 
equipment not yet available elsewhere. 

With nine components, the exhibit 
allows both children and adults to create 
animation, manipulate four-dimen- 


is expected to grow to 400 when the 
dozen or so networks are finally con¬ 
nected in 1988. As the regional net¬ 
works are expanded, this number will 
increase further to several thousand 
campuses by 1990. 

“Three hundred years from now, 
people will not even remember what a 
supercomputer was,” said Kenneth G. 
Wilson, director Cornell’s supercom¬ 
puter center. “Rather, they’ll remember 
this as the era of the birth of large-scale 
computer networks.” 


ballot for an eventual statewide ratifica¬ 
tion vote. 

If ratified, the measure would guar¬ 
antee freedom-of-expression rights to 
electronic communications and protec¬ 
tion against unwarranted search and 
seizure of personal information stored 
in computer databases. 

Moore said that Californians already 
have broad freedom-of-expression and 
privacy rights in other forms of commu¬ 
nication but that the state’s Constitu¬ 
tion does not presently acknowledge 
newer forms of communication media 
such as electronic newsletters, electronic 
mail, and computer bulletin boards. 

Congress passed the Electronic Com¬ 
munications Privacy Act in 1986, but 
Moore said legal experts believe the fed¬ 
eral law only applies to interstate elec¬ 
tronic communications and not such 
intrastate communications. 


sional spaces, discover the art of math¬ 
ematics, and explore astrophysical 
phenomena without the fear of making 
mistakes, breaking the equipment, or 
getting lost in the software. Several 
levels of control allow anyone, from a 
young child to a long-time engineer, to 
learn and be challenged. 

The exhibition is a pilot study of the 
use of interactive digital television as a 
medium for learning. The electronic 
visualization laboratory at the univer¬ 
sity is developing general-purpose, 
interactive, picture-based teaching 
machines that educators can tailor to 
their particular specifications. These 
installations are the first manifestations 
of what is possible with this new tech¬ 
nology. 


New bid planned for California law on 
electronic communications safeguards 


‘Interactive Image’ exhibition launched 
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NSF grants to five universities launch experimental research facilities 


The National Science Foundation has 
awarded five US universities a total of 
$3.8 million in first-year grants to help 
establish, enhance, and operate major 
experimental computer research facilities. 

The schools are the Georgia Institute 
of Technology, Princeton University, 
Purdue University, Rice University, and 
the University of Washington. 

Funded on an annual basis, the grants 
are expected to total more than $16.6 
million by the end of the planned five- 
year period. 

By campus, the respective first-year 
and five-year amounts were announced 
as: Georgia Tech, $708,360 and $3.4 
million; Princeton, $548,860 and $2.6 
million; Purdue, $866,640 and $3.9 mil¬ 
lion; Rice, $843,934 and $3.1 million; 
and Washington, $826,842 and $3.6 
million. 

At Georgia Tech, the first-year grant 
will help support the further develop¬ 
ment of a distributed-object-filing sys¬ 
tem to support named, permanent 
objects; port the college’s Clouds kernel 
to more modern machines; and, eventu¬ 
ally, provide a distributed operating 
system on top of the kernel, supporting 
such features as object migration for 
load balancing, a fault-tolerant job 
scheduler, global system monitoring 
systems, backing for multi-cluster struc¬ 
turing, and transparent replication of 
objects. The Clouds project is a 
research effort directed toward the 
development of a distributed object- 
based computer system. 

The NSF funds will also enable Geor¬ 
gia Tech to establish a new shared- 
memory multiprocessor system and a 
number of new workstations to aug¬ 
ment equipment already available on 
campus. 

Princeton, which has a new depart¬ 
ment of computer science, will use its 
initial award in conjunction with uni¬ 
versity support to establish and operate 
a research computing environment 
capable of serving as the basis for 
experimental computer science research 
activities into the next decade. 

Research at Princeton includes work 
in programming languages, graphical 
representations of mathematical 
objects, very large scale integration 
(VLSI) layout algorithms and tools, 
design, and analysis of data structures, 
and algorithm animation. 

The Princeton facility includes high- 
performance workstations and advanced 
personal computers and, with the pri¬ 
mary VAX equipment provided by the 
university, will serve the needs of many 
diverse projects. 

The project at Purdue is planned to 


develop tools that integrate design and 
inspection of computational models of 
physical objects with simulation and 
analysis of their behavior and interac¬ 
tion. The tools will create and manipu¬ 
late geometrical shapes, simulate 
physical processes, help control the 
power of multicomputers, and provide 
a natural, uncluttered environment for 
their users. Based on ongoing work at 
Purdue, the project will utilize new 
workstations, a tightly coupled multi¬ 
processor, sophisticated graphics sys¬ 
tems, and access to a supercomputer 
system. 

The Purdue grant will permit sub¬ 
stantial expansion of current work in 
geometric modeling and mathematical 
software. 

The first-year grant to Rice will go 
toward the creation of a parallel soft¬ 
ware laboratory called Parasol. This facil¬ 
ity is intended to support a variety of 
projects investigating both the fun¬ 
damental nature of parallel computing 
and its application to problems of 
importance in software engineering and 
scientific computing. 

The Rice award provides funding for 
a tightly coupled multiprocessor and a 
number of workstations. 

Washington will receive funding ear¬ 
marked for a project designed to pro- 


Researchers at the University of 
Illinois say they think they have passed 
a major milestone in their quest to 
develop a new generation of general- 
purpose, multiprocessing supercom¬ 
puters. 

Computer engineers at the school’s 
Center for Supercomputing Research 
and Development have installed a key 
component they designed for the experi 
mental supercomputer Cedar and have 
begun testing it. 

“This marks the transition from the 
design phase to the debugging phase for 
Cedar system hardware,” said Edward 
Davidson, the center’s associate direc¬ 
tor for hardware. 

The new component, a global inter¬ 
face board, acts as a bridge from each 
Cedar processor to the supercomputer’s 
main network and memory. 

Cedar will be a large-scale multipro¬ 
cessing computer comprised of several 


mote the understanding and effectiveness 
of parallel computing. 

The Washington work will utilize a 
shared-memory multiprocessor, a net¬ 
worked multiprocessor, and a number 
of workstations. It will involve groups 
of people with recognized strengths in 
computer architecture, performance 
analysis, image analysis and graphics, 
programming environments, computer 
systems, and computation theory. 

The NSF said the five colleges have 
made substantial commitments to sup¬ 
port the researchers and their projects, 
and will assume increasing project costs 
each year throughout the grant period. 
The facilities are expected to gain self- 
sufficiency by the end of the five-year 
period. 

In addition, each institute has indi¬ 
cated that the support the NSF is 
providing for equipment, maintenance, 
technical support staffing, and other 
appropriate costs related to its facility 
will enable it to perform significantly 
increased or improved research than 
would separate support, at the same 
total funding level, for individual 
research projects or equipment acqui¬ 
sition. 

The NSF made the grants under what 
it calls its Computer and Information 
Science and Engineering (CISE) Institu¬ 
tional Infrastructure program. 


Alliant FX/8 minisupercomputers. Each 
FX/8 has a cluster of eight processors, 
and will be linked and run as a single 
supercomputer. 

The FX/8 has been modified to 
accept global interface boards, which 
are 12-layer printed circuit boards. 

Each is nearly two feet square and con¬ 
tains 600 mostly surface-mounted inte¬ 
grated circuit chips with 20,000 
interconnections. 

The center’s hardware group has also 
designed a network board and memory 
board. The interface board is the first 
to be tested, Davidson said. 

“This demonstrates the feasibility of 
our basic hardware approach and is a 
major milestone toward producing 
faster generations of supercomputers,” 
said David Kuck, director of the center. 

Created in 1985, the center is sup¬ 
ported by the US Dept, of Energy and 
the National Science Foundation, 
among others. 


University’s researchers cite a key 
milestone in supercomputer development 
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MCC board okays superconductivity initiative 


The board of the Microelectronics 
and Computer Technology Corp. has 
approved creation of a program 
designed to investigate the electronic 
applications of high-temperature super¬ 
conductors. 

The initiative, called the MCC Super¬ 
conductivity Program though not 
limited to MCC’s 20 US shareholder 
corporations, is planned in two phases. 

Phase I will include: 

• Modeling of key technical issues in 
electronic applications, such as 
tradeoffs of copper versus super¬ 
conductors for interconnect as a 
function of temperature; perfor¬ 
mance of hybrid semiconductor/ 
superconductor systems for both 
analog and digital applications; and 
use of superconductors in active 
devices, such as sensors. 

• A comprehensive evaluation of 
technology developments focusing 
on progress in materials, fabrica¬ 


tion, and devices, along with a 
determination of requirements and 
priorities for electronic applications. 

• A series of exploratory experiments 
designed to demonstrate the feasi¬ 
bility of high-temperature super¬ 
conductors in electronic applications. 

The study and experimental work, 
slated to begin this month, will form the 
basis for a second phase set to begin in 
late 1988. In Phase II, MCC will under¬ 
take projects identified as high priority 
in the initial phase, including materials 
preparation, patterning, and processing 
techniques that will allow development 
of useful electronic circuits. Phase II 
will also include device research and de¬ 
velopment for novel applications of 
superconductors to electronics. 

Participation in Phase I will cost each 
MCC member company $100,000 and 
each non-MCC organization $100,000 
plus an annual $25,000 associates pro¬ 
gram fee. 


Sociologist develops software 
for solving social problems 


A University of Utah sociologist has 
developed computer software that uses 
artificial intelligence techniques to solve 
social problems. 

Gerald W. Smith devised a series of 
programs he calls CADA (Computer 
Assisted Decision Analysis) that incor¬ 
porate “a general system of human-like 
decision making. ’ ’ 

Over the next 50 years, specialized 
computers could change the roles of 
marriage counselors, financial consul¬ 
tants, negotiators, tax experts, middle 
managers, and teachers, said Smith. 

“Machines will not replace the 
human hand and mind, but supplement 
and expand the range of human capa¬ 
bilities,” he said. 

CADA is a general model or template 
of human decision-making logic and 
has been “tested and found to be highly 
functional in a variety of complex situa¬ 
tions,” he added. Smith said he used it 
as the basis for about a dozen special- 
purpose programs ranging from soft¬ 
ware that helps teachers and school dis¬ 
tricts in pay negotiations to programs 
that assess a couple’s marital compati¬ 
bility. It has also been used in Utah to 
study how convicted criminals should 
be apportioned among prisons, commu¬ 
nity corrections facilities, and probation 
to save money while providing the pub¬ 
lic optimum protection, and to evaluate 


the effectiveness of various treatment 
programs for drug offenders. 

He said he foresees the day when 
knowledge in almost every field will be 
recorded on computer databases. Users 
facing decisions in unfamiliar fields will 
be able to use computers to find out 
what options are open to them, to 
simulate choices, and to ascertain the 
probable consequences of their deci¬ 
sions. This is one use of computers that 
is referred to as artificial intelligence. 

In the public-policy arena, citizen 
opinions and values could be written 
into decision-making programs, Smith 
said. Since the programs take decision¬ 
makers through various options and 
point out advantages and disadvantages 
of each choice, policy-makers would be 
highly conscious of their reasons for a 
decision and thus be able to explain 
their decisions. 

Still, in the long term, applying artifi¬ 
cial intelligence and computers to socie¬ 
tal and personal decision-making will 
produce both benefits and problems, he 
predicted. 

“The next decade will be exciting 
because of the promise of a more 
rational society. It will also be a terrify¬ 
ing age because of the accelerated 
change in the relationship between 
social groups and institutions,” Smith 
said. 


Museums forge joint 
collecting agreement 

The Smithsonian Institution’s National 
Museum of American History (NMAH) 
and the Computer Museum in Boston 
have signed an historic collaborative 
agreement that promises to enhance 
the computing collections of both. 

The agreement is expected to affect 
historical research, preservation, and 
exhibitry. Through it, the two institutes 
will cooperate in creating a common 
catalog or database of their collections; 
in exchanging artifacts; and in sharing 
information about programs, research, 
exhibiting, and publications. 

Arthur P. Molella of the NMAH in 
Washington, DC, said this is the first 
such agreement the Smithsonian has 
made with an institute like the Com¬ 
puter Museum, the only unit in the 
world devoted entirely to computers 
and their impact on society. It is said to 
have the largest collection of computer 
hardware in the world, and the most 
extensive assortment of robots. 

“The field is so large and there is so 
much to do that it’s necessary for us to 
make agreements in important collect¬ 
ing fields with the leading specialized 
museums,” Molella said. 

Gwen Bell, founding president of the 
private non-profit Boston institute, 
characterized the agreement as “a win- 
win situation for both museums.” She 
said collecting should not be competitive. 

Bell added that the agreement means 
building a single collection “keeps us 
from being redundant and is more time 
and cost efficient.” 

The NMAH is devoted to the exhibi¬ 
tion, care, and study of artifacts that 
reflect the experience of the American 
people. 


IEEE legislative 
agenda available 

The IEEE federal legislative agenda 
for the 100th Congress is available from 
IEEE Public Information in Washing¬ 
ton, DC. The agenda includes IEEE 
positions on retirement income benefits, 
intellectual property, computers and 
communications, technology transfer, 
professional careers of electrical and 
electronics engineers, education, energy 
policy, R&D, the US civilian space pro¬ 
gram, and technological competitive¬ 
ness. Contact IEEE Public Informa¬ 
tion, 1111 19th St., NW, Washing¬ 
ton, DC 20036. 
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NSF funding establishes four 
new materials research groups 


The National Science Foundation has 
allocated $7.4 million to sponsor four 
teams of university scientists who will 
perform basic research on materials of 
potential technological interest. 

The new so-called Materials Research 
Groups are being set up at Brown Uni¬ 
versity, Montana State University, the 
University of California at San Diego, 
and the University of Michigan. 

Brown will receive $900,000 a year 
for three years to study how materials 
deform and fracture. Research will 
include experimental and theoretical 
modeling, and will focus on under¬ 
standing the effects of temperature and 
stress rates, the relationship of micro¬ 
scopic mechanisms to materials 
behavior, localized deformation 
mechanisms, and the role of surfaces 
and interfaces. 

Montana State’s three-year grant will 
total $1.7 million, including $590,000 


during the first year. Efforts will be 
directed toward better understanding 
basic properties of semiconductor gal¬ 
lium arsenide and related compounds, 
including how these compounds 
“grow” during manufacturing 
processes. 

UC San Diego will be awarded 
$550,000 annually for three years to 
study the microscopic properties of 
magnetic materials in thin-film and par¬ 
ticulate form, including materials used 
for storage in tape and disk recording. 

Michigan will get $343,000 the first 
year and an additional $1 million over 
the following two years to study ways to 
toughen glassy polymers, a matter of 
great importance in the development of 
new engineering plastics and composites. 

The four grants bring to 15 the num¬ 
ber of university-based groups the NSF 
has established since the program’s 
inception in 1985. 


New copyright forms needed for software 


New forms of copyright protection 
are needed for computer software, 
according to Georgetown University 
law professor Peter S. Menell. He sug¬ 
gested that Congress consider creating a 
hybrid form of patent protection specif¬ 
ically tailored for computer operating 
systems and a special form of legal pro¬ 
tection for computer application 
programs. 

A hybrid patent law, according to 
Menell, should 

• provide for timely review of patent 
applications; 

• have the traditional standards for 
protection of novelty, nonobvious¬ 
ness, and usefulness; 

• have shorter duration than tradi¬ 


tional patent protection; 

• permit some limited form of reverse 
engineering; and 

• contain a flexible, compulsory 
licensing provision. 

This would promote access to an indus¬ 
try standard while assuring rewards to 
the creator of an innovative and socially 
valuable operating system. It would 
also limit the ability of dominant firms 
to engage in anticompetitive practices. 

Menell recommended that Congress 
“appoint a new commission comprised 
of computer scientists, economists, and 
lawyers to study these problems in 
depth.” 

Menell’s ideas appeared in the July 
1987 Stanford Law Review. 


Japanese, American contrasts may decline 


According to Stanford economist 
Masahiko Aoki, “In this era of increas¬ 
ing internationalization, there seems to 
be a growing convergence of certain 
aspects of the firm.” For example, 
Japan has already found a relatively 
efficient way to incorporate employee 
interests into managerial policy making. 
He noted the worldwide trend in such 
diverse developments as codetermina¬ 
tion, collective bargaining, and employee 
stock ownership plans. 

Aoki predicted that Japanese workers 
will become more accustomed to chang¬ 


ing jobs and employers than in the past. 
One result would be increased liquidity 
of assets now tied up with their jobs. 

Core funding for Aoki’s research 
came from the National Institute for 
Research Advancement in Tokyo and 
the East-West Center in Honolulu. The 
Japan Foundation assisted in the publi¬ 
cation of Aoki’s book, The Political 
Economy of Japan: The Domestic 
Transformation, put out by Stanford 
University Press. It is the first of three 
volumes. 



CS member speaks from 
experience on merits 
of IEEE Congressional 
Fellowship program 


Mark Pullen 

The period from September 1985 
through August 1986 was one of the 
most exciting, challenging, and produc¬ 
tive times in my life. A member of the 
Computer Society, I had been selected 
the previous spring by the IEEE as one 
of its Congressional Fellows to serve on 
the staff of Congress for a year. 

These fellowships offer an opportu¬ 
nity to become deeply involved in one 
of the United States’ most important 
institutions, learn a great deal, meet and 
work with a fascinating group of peo¬ 
ple, and contribute in a meaningful way 
to the future of the country. 

The idea behind the fellowships is 
that the Congress needs help and, in 
scientific and technical areas, needs it 
badly. The Congressional staff includes 
very few scientists and engineers, and 
the presence of computing professionals 
is extremely rare. 

Shortly after accepting an assignment 
on the staff of the Committee on 
Science and Technology of the House 
of Representatives, I was being called 


Congressional Fellows 
applications available 

The 16th annual competition is 
now underway for the two Con¬ 
gressional Fellowships the IEEE 
is planning to award for the 
1988-89 term. Applications must 
be postmarked no later than 
March 31, 1988, to qualify for 
consideration. 

Application forms and further 
information may be obtained by 
calling W. Thomas Suttle at (202) 
785-0017 or by writing to Secre¬ 
tary, Congressional Fellows Pro¬ 
gram, IEEE, 1111 19th St., NW, 
Suite 608, Washington, DC 20036. 
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Computer Society officers, board members 
elected; constitutional amendments voted 


The IEEE has announced the results 
of the 1988 Computer Society balloting 
for three officer’s posts, 10 slots on the 
Board of Governors, and three constitu¬ 
tional amendments. 

Of the 64,121 ballots distributed by 
first-class mail to society members in 
early August, 9047 or 14.1 percent 
arrived at IEEE headquarters by the 
September 15 deadline, thus qualifying 
to be counted. Last year, 15.1 percent of 
the distributed ballots were cast. 

Officers. The positions of president 
elect, first vice president and second 
vice president were up for election; two 
candidates vied for each post. The win¬ 
ners are indicated below and will serve 
one-year terms starting January 1, 

1988. 

President elect: 

Kenneth R. Anderson (elected) 
Michael C. Mulder 

First Vice President: 

P. Bruce Berra 
Helen M. Wood (elected) 

Second Vice President 
Paul L. Borrill 
Joseph E. Urban (elected) 

Board of Governors. Eighteen men 
and women were candidates, and the 10 
receiving the highest number of votes 
were elected to two-year terms, also 
beginning January 1, 1988. The results 
were as follows: 

Bill D. Carroll (elected) 

Gerald L. Engel 
Lansing Hatfield (elected) 

Barry W. Johnson 


Duncan H. Lawrie (elected) 

Raymon Oberly 
Anthony Pau 
David Pessel (elected) 

Ralph Preiss 

V. Thomas Rhyne 

Susan L. Rosenbaum (elected) 

Roland J. Saam 

Sallie V. Sheppard (elected) 

Bruce D. Shriver (elected) 

Michael Smolin 
Harold S. Stone (elected) 

Akihiko Yamada (elected) 

Marshall C. Yovits (elected) 

Constitutional Amendments. All the 

proposed constitutional amendments 
received the required two-thirds affirm¬ 
ative votes and, therefore, were 
approved. 

Balloting on amendments to Article 
III, Sections 1, 2, and 9 to extend the 
terms of Board of Governors members 
to three years and to enact related 
changes passed by a vote of 7350 to 
628. Currently, Board members serve 
two-year terms. 

In the vote to amend Article IV, Sec¬ 
tion 3, concerning the succession to 
offices, the polling went 8049 for and 
460 against. Henceforth, the first vice 
president will automatically become the 
president elect if the latter office 
becomes vacant. If the first vice presi¬ 
dent is unable to serve in the president 
elect post, the board will be permitted 
to fill the vacancy. 

The voting to amend Article IV, Sec¬ 
tion 8, related to vacancies in offices 
and succession to them, tallied 7872 in 
favor and 554 against. This measure 
allows the board to fill office vacancies 
if no succession procedure is in effect or 
if the established procedure fails. 


on to advise other Committees and the 
Congressional Research Service. 

In sponsoring a few of its members to 
assist the professional staff on the Hill, 
the IEEE fulfills part of the obligation 
we have as a profession—to use our 
specialized knowledge for the public 
good. 

The time and money invested pay off 
handsomely for the fellows, who learn 
and grow more in one year than they 
could in several years spent in many 
other ways; for the IEEE, which has 
earned a reputation as a truly public- 
spirited organization that can be called 
on by the Congress for expert assistance 
and testimony; and, most of all, for the 
people of the United States, who get a 
Congress which is better able to make 
more informed decisions in creating the 
laws which affect us all. 

A new fellow soon comes to learn 
that Congress isn’t just 535 elected 
members in the House and Senate; it is 
an institution with about 40,000 
employees. 

As part of an excellent orientation 
presented by the American Association 
for the Advancement of Science, the 
fellow learns the roles of such organiza¬ 
tions as the General Accounting Office, 
the Office of Technology Assessment, 
and the Library of Congress. Even 
more important is the information 
acquired on the operation of the per¬ 
sonal and committee staffs that directly 
support and advise the members of 
Congress. 

Most fellows fill these roles, either 
working personally for an elected mem¬ 
ber or with a group of experts who 
draft legislation, monitoring the biggest 
concern of the Congress (the budget), 
keeping up with oversight issues by 
scheduling hearings and, of course, 
drafting letters and speeches. 

As with any large organization, there 
is a regular bureaucratic process to it 
all, but a fellow can find a niche based 
on special qualifications and can become 
productive almost immediately. 

The whole process really is “democracy 
in action,” a messy thing at best, full of 
conflict and confusion, but the most 
effective way we have been able to 
devise to run our country. 

It is difficult to fully comprehend the 
need Congress has for computer scien¬ 
tists and engineers. About a month 


after the orientation course began, I 
was accepted on a committee staff; 
within a week, I was sitting with mem¬ 
bers of Congress at hearings and writing 
changes to proposed legislation on com¬ 
puter security in the federal government. 
I worked on the staff of the Subcom¬ 


mittee on Science, Research, and Tech¬ 
nology, chaired by Rep. Doug Walgren 
(D-PA). 

During the year, I was also responsi¬ 
ble for staffing such actions as the 
budget authorization for the National 
Bureau of Standards (with particular 
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emphasis on the Bureau’s Institute for 
Computer Science and Technology), for 
a chapter in the report of the Science 
Policy Task Force about Science and 
the Information Age, and for a bill to 
upgrade personnel management of 
scientists and engineers and to enable 
the federal government to pay them 
competitive salaries. 

One thing I find puzzling is the small 
number of Computer Society members 
who take an interest in these fellowships. 
While the society includes a large por¬ 


tion of the membership of the IEEE, I 
was only the fourth CS member out of 
roughly 30 fellows the IEEE has 
sponsored. 

I would like to encourage qualified 
computer scientists and engineers to 
apply to participate in this fascinating 
program. 

To qualify, you must be have been a 
full member of the IEEE for at least 
four years (senior members and IEEE 
fellows are preferred), be a US citizen, 
be available to spend a year in Washing¬ 


ton (moving expenses and up to half of 
a fellow’s salary are paid by the IEEE), 
and be considered by the selection com¬ 
mittee to be well qualified to represent 
the profession in the public policy 
arena. 

The competition is getting stiffer 
every year, but I am certain that the 
Computer Society has many qualified 
candidates. If you are eligible and avail¬ 
able, why not apply? The result could 
be one of the most memorable years of 
your life. 


Society members strongly opposed to anti-consultant tax provision 


By a ratio of 10 to 1, members of the 
Computer Society have indicated they 
favor the repeal of Section 1706 of the 
US Tax Reform Act of 1986. 

In the September 1987 edition of 
Computer, society members were asked 
to cast their votes either in favor of or 
in disagreement with the position the 
Board of Governors had taken oppos¬ 
ing the legislation. 

Through mid-October, the tally was 
running 121 to 12 in agreement with the 
board’s stand. 

In the preference poll, members were 


Forty-five papers organized into 
five sections in which the 
designs and applications of 
various supercomputers are 
discussed. 

Order #581 
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asked to participate by marking the 
appropriate number on the Reader Ser¬ 
vice card that appears in each issue of 
the magazine. Those who agreed with 
the board’s action were asked to circle 
Number 191, while those disagreeing 
with the board were asked to circle 
Number 192. 

The margin of the vote might be con¬ 
sidered even more remarkable in light 
of the fact that, due to a typographical 
error, the number 191 (favoring the 
board’s action) did not even appear on 
the card. Instead, the number 190, 
which pertained to information about a 
society computer bridge contest, appeared 
twice. The number 192 (in disagreement 
with the board’s stand) did indeed 
appear on the card. Interestingly, this 
error (two 190s and no 191) had been 
repeated each month since the card was 
revised in May 1987 to include the num¬ 
bers 169 through 204. The error had 
previously gone unnoticed. 

Nonetheless, the participating mem¬ 


bers made it clear in their responses that 
they do favor revoking the tax provision 
and want Congress to define what con¬ 
stitutes an employee of a company and 
an independent contract. 

The board had unanimously passed a 
resolution aligning the Computer Soci¬ 
ety with other professional organiza¬ 
tions calling for the repeal of Section 
1706, and President Roy Russo wrote to 
Rep. Dan Rostenkowski (D-IL) of the 
House Ways and Means Committee 
notifying the Congressman of the soci¬ 
ety’s stand of the issue. 

The section has been found to be 
harmful to independent computer con¬ 
sultants because it sets professionals 
like programmers, engineers, and 
draftsmen apart from others for tax 
purposes and forces them to become 
employees of the companies they’re 
consulting for. Under the legislation, 
independent contractors and employees 
are treated differently when it comes to 
tax-deduction allowances. 


ICCP certification requirement revised 


The Institute for Certification of 
Computer Professionals has revised one 
of its regulations. The ICCP has elimi¬ 
nated the requirement that each appli¬ 
cant must have 60 months of experience 
before sitting for the Certified Data 
Processor or Certified Systems Profes¬ 
sional examination. 

Anyone who wants to can now take 
the exams, although certificates will not 
be issued to those who pass until after 
the 60-month experience requirement is 
fulfilled. 

The ICCP took this action on the advice 
of college and university representatives 
who said that the opportunity to take 
the exams is a valuable and important 
asset to graduating students. 

The process of sitting for the exams 


allows a student to establish a knowl¬ 
edge base that can be used in job 
searching, it was stated. Both exams 
have questions that require the examinees 
to have job experience, and those who 
don’t have such experience may find the 
exams difficult to pass. 

When an applicant is notified if he or 
she passed or failed, a score report indi¬ 
cates how well the examinee fared on 
each section of the exam. 

The next examinations are scheduled 
for November 14 at 160 sites around the 
world. 

Complete information on requirements 
and registration may be obtained by 
contacting the ICCP, 2200 E. Devon 
Ave., Suite 268, Des Plaines, IL 60018; 
(312) 299-4227. 
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CALL FOR PAPERS 


1988 IEEE Symposium on 
Security and Privacy 


April 18-21, 1988 
Oakland, California 


sponsored by ^ 

The Computer Society of the IEEE ^ 

Technical Committee on Security and Privacy 

in cooperation with 

The International Association for Cryptologic Research (IACR) 


The symposium will address advances in the design, implementation, evaluation, and application of secure computer systems. Privacy 
issues will also be addressed. Papers and panel session proposals are solicited in the following areas: 

• Operating System Security • Formal Security Models • Privacy Issues 

• Network Security • Authentication • Cryptographic Protocols 

• Data Base Security • Applications of Cryptography • Security Testing & Evaluation 

Papers of exceptional interest and merit will be selected for publication in a special issue of IEEE Transactions on Software Engineering. 

For further information concerning the symposium, contact: 


Dave Bailey, General Chairperson 

Terry V. Benzel, Vice Chairperson 

US Department of Energy 

The Mitre Corporation 

Production Operations Division / CIM Office 

Burlington Road 

P. O. Box 5400 

Bedford, MA 01730 

Albuquerque, NM 87115 

(617) 271-3295 or tcvb@mitre-bedford.arpa 

(505) 846-4600 or db%a@lanl.gov 


The Program Co-Chairpersons are: 


Steve Lipner 

Tom Berson 

Digital Equipment Corporation 

Anagram Laboratories 

MS: LTN 2-2/108 

P. O. Box 791 

305 Foster Street 

Palo Alto, CA 94301 

Littleton, MA 01460 

(415) 324-0100 or berson@kl.sri.com 

(617) 486-6088 or lipner%ultra.dec@ dec wrl.dec.com 



Program Committee 

Jim Anderson, James P. Anderson Co. 

Vickie Baxter, Hughes 

Terry V. Benzel, MITRE 

Earl Boebert, Honeywell 

Debbie Cooper, Unisys 

Paul Cudney, Unisys 

Nigel Day, TopExpress, Ltd. 


Deborah Estrin, USC 

Fred Grammp, Bell Laboratories 

Paul Karger, Digital Equipment Corp. 

Dick Kemmerer, UCSB 

Steve Kent, BBN 

Stan Kurzban, IBM 

Steve LaFountain, NCSC 


Carl Landwehr, NRL 
Teresa Lunt, SRI 
Cathy Meadows, NRL 
Dan Nessett, LLNL 

Marv Schaefer, Trusted Information Systems 
Dan Schnackenberg, Boeing 
Mario Tinto, NCSC 


Send 5 copies of paper, extended abstract (at least 2000 words), or panel proposal by November 27, 1987, to Steve Lipner at the address 
above. Authors will be notified of acceptance by January 22, 1988. 

FINAL PAPERS ARE DUE NO LATER THAN FEBRUARY 22, 1988. 
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Low-cost CASE: tomorrow’s promise emerging today 


Giovanni Perrone, Martin Marietta Astronautics Group 


Computer-aided software engineering 
(CASE) is one of the fastest growing 
market segments in computer technol¬ 
ogy. International Data Corp. esti¬ 
mated CASE market growth to be 35 
percent a year and predicted that it will 
exceed $1 billion by 1990. 

Currently used to classify a broad 
range of automated systems and soft¬ 
ware engineering tools, CASE generally 
refers to the automation of any soft¬ 
ware engineering task. Because software 
costs typically represent more than 80 
percent of total system costs in most 
major systems, the term software 
dominates the acronym. However, 
CASE products—especially integrated 
CASE environments—could just as eas¬ 
ily be defined as automation of the sys¬ 
tems engineering process, since software 
engineering is a subset of systems 
engineering whenever a system requires 
software. 

CASE products range from stand¬ 
alone tools that automate a specific 
software engineering task to complete 
environments that automate most of the 
tasks in the software engineering life 
cycle. Long regarded as the domain of 
scientific and technical users, software 
engineering principles and techniques 
are increasingly used in the commercial 
arena. Consequently, CASE products 
originally thought to have the most 
appeal for use in scientific, government, 
and military applications are increas¬ 
ingly applied to (and developed or 
adapted for) commercial applications. 

The ideal CASE product will span the 
complete system development life cycle 
and integrate its over one hundred 
necessary functions, providing the flexi¬ 
bility to support a variety of methodol¬ 
ogy and documentation requirements. 
Because such a product is not available 
at this time and those that come close 
are costly, many development firms are 
turning to low-cost PC-based products. 
Virtually all organizations involved in 
the computer systems development 
business continually search for low- 


cost, flexible, automated tools that 
improve productivity. This search is not 
restricted to small organizations with 
limited funding, either; major corpora¬ 
tions must also strive to lower costs of 
the automated tools they make avail¬ 
able for all their system developers. 

Until recently, CASE tools support¬ 
ing structured development have been 
priced around $10,000 and higher. In 
spite of their utility, this pricing puts 
them out of the reach of small firms 
and restricts their use in even the largest 
firms. A new set of low-cost tools now 
emerging provide a more specialized 
capability and interface well with other 
system development tools. This column 
explores the potential of four low-cost 
PC-based CASE tools and summarizes 
their features and capabilities. 


The case for CASE 

Computer technology is developing 
faster than any technology in our his¬ 
tory, with gains in price/performance 
approaching six orders of magnitude 
over the past 30 years. Computer speed 
and power are now increasing at about 
30 percent a year, but software develop¬ 
ment productivity is increasing only 
four to seven percent a year. The soft¬ 
ware systems of today represent new 
levels of power and complexity that 
greatly exceed the capabilities of tradi¬ 
tional development processes. The task 
of developing and maintaining new 
software—difficult to manage, intellec¬ 
tually taxing, and time consuming—has 
clearly become the critical task of new 
systems development. The costs 
associated with software are becoming 
prohibitive. 

Recognized in the early 1970s as a 
problem for Department of Defense 
embedded computer applications for 
mission-critical computer resources, the 
“software crisis” is now widely 
accepted as common to all types of sys¬ 


tems and applications, including com¬ 
mercial ones. In 1985, embedded 
applications alone cost the DoD $10 bil¬ 
lion, and the federal government spent 
$36 billion for software development 
and maintenance. An IBM estimate 
shows greater than $135 billion as the 
1986 worldwide cost of software devel¬ 
opment and maintenance. The backlog 
of software applications needed by cor¬ 
porations now averages 30 months, an 
increase of over 50 percent in the last 
five years. And more people is not the 
solution. We have always had an acute 
shortage of skilled software profes¬ 
sionals, at all levels. A DoD study indi¬ 
cates that the demand for qualified 
software personnel is increasing at 12 
percent annually, while the supply of 
qualified software personnel and their 
average productivity are increasing at 
only four percent annually. We badly 
need new development and maintenance 
methods. 

Current evidence suggests that auto¬ 
mation of the software engineering 
process improves productivity, reduces 
costs, and results in higher-quality soft¬ 
ware. Even though the claims are not 
normally substantiated quantitatively 
and surveys show increases ranging 
from 30 to 600 percent, the surveys do 
show increases. 

Since its inception in the late 1960s, 
software engineering has offered a radi¬ 
cally different approach for the devel¬ 
opment of computer software. Initially 
devised to formally apply sound 
engineering principles to the develop¬ 
ment of programs for large and com¬ 
plex systems, software engineering 
techniques are currently used for the 
development and maintenance of all 
types of software. The radical differ¬ 
ence in the software engineering 
approach can be found in its two major 
contributions: the life-cycle concept and 
structured development techniques. A 
possible third major contribution 
emerging since the early 1980s is rapid 
prototyping. 
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The life-cycle concept simply projects 
the idea that software development fol¬ 
lows a planned life cycle. The life cycle 
depicts the phases of the development 
process, with specific steps defined for 
each phase. Usually, one or more 
products and formal milestones or 
reviews occur with each phase. Many 
variations of the life cycle have been 
specified; a customer’s specification of 
the life cycle is, of course, always the 
correct one to use. Nevertheless, the life 
cycle can be generalized with six phases: 
analysis, design, coding, testing, imple¬ 
mentation, and maintenance. 

In the analysis phase the require¬ 
ments are determined and formally 
documented. A requirements specifica¬ 
tion is the primary product of this 
phase. 

The design phase uses the specified 
requirements to develop the software 
design. A design document typically 
results. 

The coding (programming) phase 
uses the specified design as a blueprint 
for the software. In addition to the 
actual software, various listings and 
operational manuals result from this 
phase. 

The testing phase validates the design 
by verifying that the software satisfies 
the requirements. Testing usually 
requires a detailed test plan prior to 
start and test reports at completion. 

During implementation the software 
and all required documentation are 
delivered to the customer. The success¬ 
ful completion of customer acceptance 
testing marks the end of this phase. 

The maintenance phase, not previ¬ 
ously considered a part of the software 
development process, is now commonly 
included in the life cycle. Maintenance 
includes the repair, modification, and 
enhancement of the software for its 
remaining life. Since the remaining life 
is usually many times the time required 
to produce the software, maintenance 
costs typically exceed development costs 
significantly. 

Structured development techniques 
have emerged since the early 1970s as 
the preferred method for developing 
complex computer systems. The most 
popular techniques—structured analy¬ 
sis, structured design, and structured 
programming—have generally improved 
productivity and effectiveness in many 
organizations. 

Structured analysis is considered one 
of the most important of the structured 
techniques. Analysis is the first phase of 
the computer system development pro¬ 
cess, where the user’s requirements are 
defined and documented. Structured 
analysis provides guidelines and graphi¬ 
cal communications tools that enable 


the systems analyst to construct a sim¬ 
plified, structured “mini” specification 
that users can actually understand. It 
improves the communications process 
between users and system developers, 
and results in a better understanding of 
the system by both. 

A structured methodology defines the 
guidelines and graphical symbols that 
enable the developers to construct sim¬ 
plified and uniform specifications. 
Unfortunately, none of the structured 
methodologies has become a standard 
that all system developers use. Almost a 
dozen popular methodologies are used 
now. It is common to find informal var¬ 
iations in methodology use, even within 
the same organization. Each structured 
methodology uses a slightly different set 
of graphic symbols and rules. Since its 
introduction in 1976, the structured 
analysis process has been refined into a 
practical discipline by more than one 
systems consulting firm. 

Rapid prototyping is gaining increas¬ 
ing popularity as a software engineering 
discipline. Like almost all emerging dis¬ 
ciplines, rapid prototyping has many 
definitions (and religious arguments for 
each). But it primarily addresses a 
major problem encountered during the 
early phases of the software life cycle. 

The problem can be simply stated in 
three parts. First, most users are not 
exactly sure of their requirements. Sec¬ 
ond, most analysts are not very good at 
determining requirements. And third, 
requirements can best be determined 
incrementally and iteratively, with a 
working model that establishes a com¬ 
mon understanding. 

A rapid prototyping solution to the 
problem boils down to abbreviating the 
analysis process to the point that you 
have sufficient knowledge of the system 
to rapidly design and develop a working 
skeletal model. Rapid prototyping 
breaks the traditional sequential 
“waterfall” flow through the life cycle 
by adding iteration as necessary in the 
first three phases. You can then use the 
model to learn (and get user acceptance) 
in increments, with process iteration. 
The results of iteration help flesh out 
the model until it accurately represents 
the requirements. A key argument at 
this point can now be triggered by the 
question, Is the model (prototype) the 
system (software)? The answer can be 
yes or no. If the model was used to rep¬ 
resent only the functional requirements 
of the system and excluded perfor¬ 
mance requirements, then the answer 
tends to be no. If performance require¬ 
ments were included, the answer tends 
to be yes. In any case, rapid prototyp¬ 
ing is proving itself a powerful dis¬ 
cipline for reducing development time. 


But the software engineering process 
itself is not enough. Involvement in a 
software development effort of any sig¬ 
nificance quickly reveals the need and 
opportunities for process automation. 
The management and administrative 
tasks alone too soon become a burden. 
The completeness and consistency of 
technical details associated with the 
software and life-cycle products become 
almost impossible to maintain. The sit¬ 
uation degrades rapidly as the number 
of people on the project increases. 

CASE tools span the entire software 
life cycle, but automation of the “front- 
end” analysis and design processes have 
gotten special attention. Misunderstood 
requirements and errors detected early 
in the life cycle are significantly easier 
to correct and result in tremendous sav¬ 
ings. Many of these front-end CASE 
tools are designed to automate a struc¬ 
tured development methodology. Better 
analysis leads to more effective design, 
easier programming, fewer testing 
errors, more success during implemen¬ 
tation, and reduced maintenance 
(already 70 to 90 percent off total soft¬ 
ware development life-cycle costs). 


Structured analysis 
methodologies 

Yourdon, Inc. has developed and 
teaches one of the most popular styles 
of structured analysis. A large part of 
this popularity results from an excellent 
book. Structured Analysis and System 
Specification by Tom DeMarco (Your¬ 
don Press, 1978) and Yourdon’s highly 
effective training program. Having suc¬ 
cessfully used, implemented, and directed 
the use of the Yourdon structured anal¬ 
ysis method on many projects (ranging 
from business-oriented systems to 
highly sophisticated real-time command 
and control systems), I find myself 
unwilling to return to traditional system 
analysis methods. 

Yourdon structured analysis requires 
four components: the data flow dia¬ 
gram, the data dictionary, the entity 
relationship diagram, and the struc¬ 
tured specification. 

The data flow diagram (DFD) is the 
primary component. A DFD graphi¬ 
cally represents the functional require¬ 
ments of a system. It portrays the 
inputs, data flows, processes (or func¬ 
tions), files (or data stores), and outputs 
of the system. 

The data dictionary contains the defi¬ 
nitions of all data flows and data stores 
modeled on the DFDs. 

The entity relationship diagram por¬ 
trays the associations (relationships) 
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between the data objects (entities) of the 
system. 

The structured (mini) specification is 
a concise written description of each 
function modeled on the DFDs. Four 
basic notational elements are used to 
construct a DFD: a square for termina¬ 
tors (also called inputs and outputs or 
sources and sinks), a circle for processes 
(functions), a labeled vector (line with 


an arrowhead) for data flows, and par¬ 
allel horizontal lines for files (stores). 

An initial DFD, the context diagram, 
defines the domain of the system. It 
shows the system as a single function 
with the major data flows, the files 
used, and the sources of inputs and 
sinks for outputs. This single, context- 
level function is decomposed into its 
subfunctions on a lower-level diagram 


(level zero) showing more detail. This 
functional decomposition continues, 
creating several more diagram levels, 
until a function can no longer be 
decomposed. A function at its lowest 
level of decomposition is called a func¬ 
tional primitive. The entire set of 
leveled diagrams graphically represents 
the functional requirements of the 
system. 

The traditional way to construct 
DFDs, of course, is with pencil and 
paper. And the simple notational ele¬ 
ments make this an adequate alterna¬ 
tive. However, as the decomposition 
process yields more complex diagrams, 
and the processes, data flows, file 
names, and number of interactions 
(more than one analyst) increase, a 
manual DFD drawing method quickly 
demonstrates inherent limitations. Sim¬ 
ple rearrangement and modification 
becomes a burden because you must 
redraw the DFD. Consistency in data 
flow names from DFD to DFD becomes 
a problem, even with the same analyst. 
Manually, the process is laborious and 
error-prone. Automated or electronic 
construction of DFDs resolves many of 
these problems and facilitates solutions 
to many more. 

Other popular structured analysis 
methodologies in use are Gane and Sar- 
son and Warnier-Orr. The processes, 
techniques, and products of these other 
methodologies resemble Yourdon, but 
the rules, terminology, and symbols 
employed differ. Gane and Sarson, for 
example, uses a rounded square (instead 
of a circle) as the process (function) 
symbol. In addition, two enhancements 
to the basic Yourdon methodology have 
become popular for real-time systems: 
the Derick Hatley and the Paul Ward/ 
Steve Mellor extensions. Both extend 
the basic capability by adding mechan¬ 
isms to support control, timing, and 
sequencing. The mechanisms include 
control flow diagrams, state transition 
diagrams, state/event matrices, process 
activation tables, and decision tables. 

Typically a customer specification, 
project requirement, or user preference 
determines the methodology for a given 
project. So an important feature of any 
structured analysis tool is enough flexi¬ 
bility to support the user’s choice of 
methodology. If this flexibility allows a 
user to customize a methodology, so 
much the better. 


Low-cost structured 
analysis tools 

Four comparatively low-cost struc¬ 
tured development tools are available 


Low-cost CASE product comparison. 


Feature 

Visible 

Analyst 

Workbench 

Teamwork/ 

PCSA 

Anatools 

PoweiTooIs 

PC 

Environment 

IBM 

(compatibles) 

IBM 

(compatibles) 

Macintosh 

Macintosh 

Methodology 

Supported 

Yourdon/ 
DeMarco; 
Gane and 
Sarson 

Yourdon/ 

DeMarco 

Gane and 
Sarson 

Yourdon/ 

DeMarco 

User Custom 
Methodology 

Yes 

No 

No 

No 

Data Flow 
Diagrams 

Yes 

Yes 

Yes 

Yes 

Data 

Dictionary 

Yes 

Yes 

Yes 

Yes 

Structured 

“Mini” 

Specification 

Yes 

Yes 

Yes 

Yes 

Presentation 

Quality 

Output 

Yes 

Yes 

Yes 

Yes 

Consistency 

Checking 

Yes 

Yes 

Yes 

Yes 

Structured 

Design 

Support 

No 

No 

No 

Yes 

Real-time 

Extensions 

No 

No 

No 

Yes 

Export 

Capability 

ASCII 

ASCII 
and EDIF 

ASCII 

ASCII 

Copy 

Protected 

No 

Yes 

No 

Unknown 

Full Retail 

Price 

$1785 

$995 

$925 

$3295 

($4495) 
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for use on personal computers, two for 
IBM PC compatibles and two for the 
Apple Macintosh. I selected them 
because each has been available long 
enough to achieve a level of maturity. 
Each product enjoys a loyal and grow¬ 
ing base of satisfied users. A summary 
of each product’s features and capabili¬ 
ties follows. 


Visible Systems’ Visible 
Analyst Workbench (2.3) 

Visible Systems of Newton, Mass., is 
a pioneering vendor of low-cost CASE 
tools. In slightly over two years they 
have continually enhanced the Visible 
Analyst into the current Workbench 
product and now enjoy a steadily 
increasing user base. The Visible Ana¬ 
lyst Workbench is a low-cost, easy-to- 
use, PC-based charting and diagram¬ 
ming tool to create the system life-cycle 
diagrams required by any methodology. 

The Workbench currently consists of 
three separate, integratable modules. 
Tool A, the Visible Analyst, is the foun¬ 
dation diagramming tool. Tool B, Visi¬ 
ble Rules, is an add-on module that 
currently supports Yourdon or Gane 
and Sarson rules. Warnier-Orr and user 
custom rules will be available in the 
near future. Tool C, the Visible Dic¬ 
tionary, adds a central repository for 
information related to a project. 

Each tool costs $595, allowing new 
users to start with the Analyst and add 
the Rules and the Dictionary when 
required. A yearly cumulative purchase 
discount schedule reduces prices as 
more copies are purchased. In the 
50-to- 100-unit pricing bracket, the price 
is $981.75 for the complete Workbench. 

The Visible Analyst’s powerful 
diagramming capabilities (Tool A) are 
specifically tailored to the needs of sys¬ 
tem developers. They include an exten¬ 
sive, customizable symbol library; 
dynamic symbol sizing; selectable sym¬ 
bol style attributes (such as bold, relief, 
and stack); and variable line and type 
styles and type sizes. 

The Analyst supplies the circle, rec¬ 
tangle, and parallel line symbols as the 
first three elements of the standard sym¬ 
bol template. They can be used for 
Yourdon or other methodologies that 
employ the same symbols. Additional 
elements (21) provided in the template 
include the Gane and Sarson symbols 
(rounded squares), standard flowchart 
symbols, and some others. Blank spots 
in the template (16) allow users to create 
and store their own symbols. The tem¬ 
plate can hold up to 40 symbols, but 
users can create multiple templates to 


satisfy special needs. This flexibility 
allows customizing to support virtually 
any methodology. 

With the Analyst, you can easily cre¬ 
ate and nest any type of system dia¬ 
gram, such as a flowchart, data flow 
diagram, structure chart, and entity 
relationship diagram. Other graphics, 
such as organization charts, Gantt 
charts, and work flow diagrams can 
also be constructed. Mouse operation, 
frequent command prompts, and on¬ 
line help make it a very easy tool to 
learn and remember. 

Visible Rules (Tool B) provides auto¬ 
matic level-to-level balancing, con¬ 
sistency checking, data flow splitting, 
and error listings to maintain project- 
level conformance to the rules of a 
methodology. Structured methodolo¬ 
gies support a top-down decomposition 
of a project, using nested diagrams that 
show progressively more detail as a 
project’s processes and data are decom¬ 
posed. Consistency across diagrams can 
quickly become a problem as a system 
grows in complexity. Manual checking 
is error-prone and laborious. When the 
consistency checking option is enabled, 
Visible Rules checks for labels in all 
objects and data flows; for numbering 
and balanced data flows in all processes; 
for “dangling” (not connected to a 
process) data flows, files, or termina¬ 
tors; and for parent diagram to child 
diagram relationships. Checks can be 
performed on a local (single diagram) 
or global (entire project) basis. Diagram 
inconsistency error messages can be dis¬ 
played or printed. Since consistency 
checking is an indispensible element of 
any structured analysis process, poten¬ 
tial users of either Yourdon or Gane 
and Sarson methodologies will find 
Visible Rules a wise option. 

The Visible Dictionary (Tool C) adds 
a capability to track and organize 
Workbench data. The Dictionary is 
automatically populated with key infor¬ 
mation from the Analyst and Rules 
modules. Each dictionary entry has six 
user-modifiable fields that can expand 
project definitions. Wildcard and selec¬ 
tive searching and wildcard selection 
make navigating through the dictionary 
to edit entries a pleasure. Access to Dic¬ 
tionary’s entries from the Analyst’s 
graphic screens adds the flexibility to 
edit entries when the processes and data 
flows are created. Detailed, summary, 
and cross-reference reports of the proj¬ 
ect can be produced from the diction¬ 
ary. All reports can cover the entire 
project, a selected subset, or an individ¬ 
ual entry. Dictionary data can also be 
exported to ASCII files for interchange 
with other application programs, such 
as a word processor or database man¬ 


ager, for further enhancements. 

The Visible Analyst Workbench is 
not copy protected. Hard disk installa¬ 
tion is accomplished using a batch file 
provided, or by simply copying the files 
from the distribution disk to a subdirec¬ 
tory. Type “VA” to execute and a logo 
screen appears inviting users to press 
the left (L) mouse button to proceed. 
Since a two-button Microsoft Mouse is 
assumed, the center button on a three- 
button mouse remains inactive. Press¬ 
ing the left button brings up a rulered 
work screen, with the main style menu 
centered on the right margin. 

The main menu has eleven selections: 
HELP, CREATE, EDIT, VIEW, 
PRINT, CUSTOM, FILING, DICT, 
REPORT, CONFIG, and QUIT. Each 
is selected by dragging the mouse to 
highlight a choice and pressing the left 
button. CONFIG allows specifying disk 
drives, memory size, background color, 
printer features, text and line default 
values, and mouse speed. It also enables 
options associated with the Rules and 
Dictionary modules, such as consistency 
checking. CREATE is used to construct 
a new document. Existing documents 
are accessed and revised by selecting 
EDIT. As projects are created, a Proj¬ 
ect Masterfile is maintained to keep 
track of all projects (documents) on the 
system. VIEW can be selected at any 
time to show a tree-like graphical listing 
of the Project Masterfile. 

A Document Menu provides 21 addi¬ 
tional secondary commands for use 
when in CREATE or EDIT mode. 
Secondary commands are selected using 
the same drag-and-press technique with 
the mouse to perform several 
document-oriented operations. The 
commands and their associated features 
provide a lot of drawing power, with 
single-line menus to add further instruc¬ 
tions at every step. Many advanced 
drawing features allow you to easily cre¬ 
ate and modify complex diagrams and 
freely intersperse text. 

All Visible Analyst menu functions 
operate using this friendly, logical, 
mouse-driven user interface. An almost- 
always-present cancel option allows new 
or careless users to back out easily. 

The operating manual is clearly writ¬ 
ten, comprehensive, logically organized, 
and contained in a small-format three- 
ring binder. It includes a complete and 
effective tutorial. Printer support 
includes the Epson LQ series, Toshiba 
P351, Fujitsu 24D, IBM Color Jet, and 
HP Laserjet Plus. A CONSTRUCTS 
feature allows reuse of complete 
graphic structures. A large EASEL 
drawing area is also available, equiva¬ 
lent to a 14%-by-11-inch page. Individ¬ 
ual documents can be inserted into, 
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removed from, or copied within or 
between projects. 

The three strongest features of the 
Visible Analyst Workbench are: 

(1) A user can define custom symbols 
and store them in a symbol library—the 
Symbol Template—for repeated use. 

(2) Flexible mixing of graphics and 
text on the same page is allowed. 

(3) Consistency checking assures end- 
to-end conformance of project docu¬ 
mentation to the rules of a methodology. 

These features also make the Visible 


Analyst Workbench suitable for creat¬ 
ing complex documents for many other 
disciplines. A new “presentation” print 
mode provides output quality good 
enough for customer specifications. 

Among the disappointments are the 
lack of higher resolution EGA graphics 
mode: only CGA mode is currently sup¬ 
ported. But EGA graphics support will 
be added in the near future, as will 
multiuser operations on a local area 
network. 
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Cadre Technologies’ 
Teamwork/PCSA (3.0) 

Cadre Technologies of Providence, 
Rhode Island, is a CASE industry 
leader. Their Teamwork line of struc¬ 
tured analysis and structured design 
tools available for Apollo, Sun, DEC, 
and IBM RT workstations are already 
in widespread use. In early 1987, they 
acquired the exclusive rights to Struct- 
soft’s PCSA (Personal Computer Struc¬ 
tured Analysis), a low-cost, IBM PC 
software tool that supports Yourdon- 
style structured analysis. Version 3.0 
represents Cadre’s technical influence 
on PCSA, with major enhancements, a 
complete documentation rewrite, and a 
new name—Teammwork/PCSA— 
indicating the Teamwork family 
influence. 

Teamwork/PCSA Version 3.0 
includes the following major new 
features: 

• A process specification editor that 
allows processes to be defined 
within PCSA. 

• An export capability allowing a 
PCSA project to be formatted as 
either an ASCII or EDIF file for 
interchange with other products. 

• A save feature so that a project 
may be backed up into a new 
directory. 

• A quit menu choice so that a user 
can move to a new project without 
exiting PCSA. 

• Menu names more consistent with 
other Teamwork products. 

• Improved error trapping and messages. 

An early version of the new user’s 

guide shows much improvement as well. 
The Electronic Design Interchange For¬ 
mat (EDIF) export capability is signifi¬ 
cant. EDIF is the format proposed by 
Cadre to standardize data exchange 
between CASE applications (see Com¬ 
puter, June 1987, pp. 78-80). If adopted 
by the industry, it will ensure data inter¬ 
change across CASE, and maybe CAE, 
products. Currently it ensures data 
export from PCSA to workstation ver¬ 
sions of Teamwork. The exportable 
objects include data flow diagrams, 
data dictionary entries, and process 
specifications. An EDIF import capa¬ 
bility will be added to PCSA in the near 
future. 

Unlike earlier versions, Team¬ 
work/PCSA is now a complete PC 
structured analysis tool capable of 
producing data flow diagrams, a data 
dictionary, and a structured process 
specification. It only supports the Your- 
don/DeMarco, non-real-time method¬ 
ology and does not include real-time 
extensions. 



An example diagram of the Yourdon/DeMarco technique produced by the Visible 
Analyst (Tool A) module of the Visible Analyst Workbench from Visible Systems. 
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PCSA is copy protected using a hard¬ 
ware device called a block that you 
must connect to the printer port. To 
store project data files, you must create 
a projects subdirectory from DOS. 
PCSA stores all the information for 
your structured specification in one 
directory, so you can use directory 
names to identify your projects. 

The program offers high-resolution 
graphics through support of several 
popular graphics display adapters, such 
as the Hercules Monochrome Graphics 
Adapter (and compatibles), Tecmar 
Graphics Master, AST MonoGraph 
Plus, MDS Genius (738 x 1004 mono¬ 
chrome), and Wyse WY-700 (1280 x 800 
monochrome). Color support includes 
the IBM Color Graphics Adapter, 
Enhanced Graphics Adapter, and 
several adapters that provide 640 x 400 
resolution and 16 colors. 

The Mouse Systems, Microsoft, and 
compatible mice are supported. Mouse 
and display adapter-monitor combina¬ 
tions are automatically detected at 
startup, with a message confirming 
what was detected. Nonstandard con¬ 
figurations require a command line 
switch when loading PCSA to set the 
desired mode. For example, the command 

PCSA /2 /E:4 

sets up for the Mouse Systems mouse 
on serial port COM2 and the IBM EGA 
in 640 x 350 and 16-color mode. 

PCSA is very easy to use. Three inter¬ 
active screens form the interface for 
operating the DFD editor, the data dic¬ 
tionary editor, and the process specifi¬ 
cation editor. Within each editor 
screen, pop-up menus, windows, and 
forms control specific operations. Win¬ 
dows are displayed within the editor 
screens in response to requests for 
information, such as consistency check 
results or process index. Forms are used 
to obtain additional instructions, input 
text, or display error messages. 

Three types of pop-up menus are 
used: global, blank space, and object- 
oriented. The pop-up menu chosen is 
determined by cursor location. Global 
menus are selected when the cursor is 
located, and mouse button clicked, on 
an editor’s title bar. Blank-space pop- 
ups are selected by clicking on the blank 
space in an editor screen. Object- 
oriented pop-ups are selected by click¬ 
ing on an object in an editor screen. 

Ten different object-oriented pop-up 
menus provide commands relevant to 
the specific editor objects, such as bub¬ 
bles (processes), data flows, and data 
definitions. Menu command selection is 
restricted to logical (legal) commands, 
preventing execution of illegal 
commands. 

Creating the DFD elements for a 


process, data flow, source, sink, or file 
is very easy and natural. Rearranging 
the objects and reshaping data flows on 
the diagram is simply a matter of 
“dragging” the object or data flow to 
its desired new location. The top-down 
nature of structured analysis is strictly 
enforced, preventing users from ran¬ 
domly editing DFDs. Menu selections 
GoTo, Show Parent, and Show Child 
allow easy movement between DFDs in 
a project. Consistency checking of data 
flow names is one of PCSA’s strengths; 
it is performed “on the fly” as you 
travel from diagram to diagram. These 
checks warn of inconsistencies among 
data flows and processes that will cause 
problems. A message prompts users to 
display or ignore the results of these 
checks."Each message is preceded by 
*W* for warning or *E* for error to 
indicate severity. 

When constructing a project in the 
DFD editor, a title line that says “DFD 
—1: Context Diagram” appears at the 
bottom of the diagram. The context 
diagram is used to model the operating 
environment and constraints of the 
project. When a single process is 
decomposed into more detail on lower- 
level DFDs, PCSA automatically num¬ 
bers them starting with zero. The level 
zero (root) diagram is the first-level 
decomposition of the single-context dia¬ 
gram process. If £jve processes are 
shown at level zero, they are numbered 
from 1.0 to 5.0. Each of these processes 
can in turn be further decomposed with 
level one DFDs that PCSA automati¬ 
cally numbers. The level one decompo¬ 
sition for process 2.0, for example, 
would be numbered 2.1, 2.2, 2.3, and 
2.4, showing four new processes at this 
level. At the next level of decomposi¬ 
tion, say for process 2.1, the new 
processes are numbered 2.1.1, 2.1.2, 

. . . 2.1.« (where n is the highest num¬ 
ber for processes at this level). This 
numbering is consistent with the Your- 
don numbering convention. Sound 
slightly confusing? The point is that 
PCSA automatically assigns the correct 
numbering to all DFDs in an entire 
project. 

PCSA prints presentation quality 
output to a good variety of dot matrix 
and laser printers (a Postscript driver is 
also included). The prerelease version 
implies that plotters are also supported, 
but this could not be confirmed with the 
draft documentation. 

The process specification (P-Spec) is 
the frosting on the cake. It allows quick 
and easy construction of structured 
“mini” specifications. Moreover, the 
new export capability to EDIF format 
opens the door to distributed CASE 
environments, with Teamwork worksta¬ 


tion products today and maybe the 
whole CASE world tomorrow. 
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Advanced Logical Software’s 
Anatool (2.0) 

Anatool is an Apple Macintosh-based 
structured analysis tool. It runs on any 
Macintosh from the Mac 512K (with an 
800K-byte floppy drive) to the new Mac 
II. It supports Gane-and-Sarson-style 
structured analysis. Anatool was devel¬ 
oped by Abvent (Paris, France). Ver¬ 
sion 1.0 has been available in the United 
States for over a year. Anatool Version 
2.0 was released on July 20, 1987 and is 
priced at $925. Advanced Logical Soft¬ 
ware of Beverly Hills, Calif., Anatool’s 
new owner, focuses on CASE tools. 

Anatool provides a hierarchical 
graphics tool for drawing data flow dia¬ 
grams, a database for the data diction¬ 
ary, and a specialized word processor 
for creating structured English or 
“free” English specifications. These 
three structured analysis activities are 
integrated into the intuitive Macintosh 
interface with high-quality graphics, 
consistency checks, and cross-reference 
features. 

You can create the data flow dia¬ 
grams in Anatool by simply dragging 
predefined icons from a toolbox. As 
you reposition icons on the screen, the 
diagram is quickly redrawn while con¬ 
necting flows stay logically and physi¬ 
cally attached. To decompose a process, 
just double click on the process and a 
new diagram opens. The related flows 
from the parent level process are auto¬ 
matically contained on the new dia¬ 
gram. If desired, you can also create 
and integrate independent diagrams 
with complete logical consistency at 
some future time. 

Double clicking on an icon or data 
name allows access to the data diction¬ 
ary or specifications. The data diction¬ 
ary element list is loaded automatically 
from the data terms used on the DFDs 
or in dictionary definitions. Special 
windows allow you to categorize, 
define, and decompose each data term. 
The complete hierarchical data struc¬ 
ture and consistency between defini¬ 
tions are maintained. The data 
dictionary allows representation of the 
alias, basic data, data structure, data 
store, and known data categories. 

The standard (structured) specifica¬ 
tion allows you to choose from true 
English or structured English styles. 
Structured English structures are chosen 
from a menu or translated from free 
text sentences. Text indentation and 
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keyword highlighting are automatic. A 
dictionary search finds and highlights 
all data dictionary names present in the 
specification to insure consistency. A 
consistency check verifies the syntax of 
the structures and corrects the struc¬ 
tured English. 

Anatool provides three levels of con¬ 
sistency checks: instant checks, local 
checks, and full document checks. They 
can be either viewed on screen or 
printed. Instant checks help prevent 
logical errors from occurring as work 
progresses. Local checks are available 
on request from any of the three 
Anatool activities. Full document 
checks verify consistency within an 
entire single document. Both incon¬ 
sistencies and incomplete work are 
recorded by the consistency checks. 

Anatool, like most Macintosh soft¬ 
ware, provides outstanding presentation- 
quality output on either the Apple 
Imagewriter or LaserWriter printers. A 
complete document including title page 
can be printed, or just the section cur¬ 
rently needed. A complete document 
contains all diagrams in numerical 
order on letter-size paper, the standard 
specification catalog, and an alphabe¬ 
tized dictionary listing of data type and 
corresponding definition. You can also 
print a complete structure tree and 
categorized data lists. 

Version 2.0 is no longer copy pro¬ 
tected. Instead, a user must enter an 
identification (person or company 
name) to start the program. A user is 
authorized to make backup copies or 
copy Anatool once to a hard disk. An 
internal registration number can be 
used to identify unauthorized copies. 

Anatool now allows multipage data 
flow diagrams. A special page-setup 
window serves to indicate the number 
of pages of drawing space need for each 
diagram. Up to 15 processes per level, 
instead of the former nine, may be 
used. The data dictionary now has a 
capability for creating ASCII files, to 
facilitate data interchange to other 
programs. 
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Iconix Software Engineer¬ 
ing’s PoweiTools (1.0) 

Iconix of Santa Monica, Calif., has 
marketed the Prism toolset of low-cost 
CASE tools for the Macintosh during 
the past year. As of July 31, 1987 and 
starting with Prism release 1.3, the tool- 
set was renamed PowerTools. Since an 
evaluation copy was not received in 


time for this column, the following 
summary is based on the company’s 
latest announcements. 

PowerTools Version 1.0 runs on all 
Macintosh models (512K to Mac II) and 
is retail priced at $3295. It includes 
FreeFlow ($1895), SmartChart ($1495), 
and PowerPDL ($995), all available 
separately. Version 2.0, scheduled for 
the fourth quarter of 1987 at a price of 
$4495, will include FastTask ($1595) for 
full real-time system support. The com¬ 
pany claims that the PowerTools pack¬ 
age offers complete life-cycle support, 
encouraging the use of structured devel¬ 
opment methods. 

FreeFlow is a structured analysis tool 
featuring a multiple window architec¬ 
ture and hierarchical editing. It sup¬ 
ports the Yourdon/DeMarco structured 
analysis method and includes real-time 
extensions. A consistency checker 
assesses diagram and data dictionary 
completeness, assures balancing 
between parent and child diagrams, and 
provides consistency reports. Diagram 
primitive processes are collected from 
minispecs and form an input file usable 
with PowerPDL. The minispec editor 
creates process specifications from the 
primitives. A data dictionary automati¬ 
cally stores the data and control flow 
from the DFDs. FreeFlow outputs are 
data and control flow diagrams, 
minispecs, the data dictionary, con¬ 
sistency reports, and the skeleton PDL 
file. An ASCII bridge reformats files 
for export to other programs. 

SmartChart combines a structure 
chart generator with a language- 
sensitive editor to support successive 
refinement of the FreeFlow skeleton 
PDL file. It automatically draws and 
labels structure charts from the infor¬ 
mation contained in the PDL file. A 
multiwindow architecture lets a designer 
browse structure charts and text simul¬ 
taneously, to visualize program struc¬ 
ture and refine the PDL. Keyword 
templates provided by pull-down menus 
allow source code to be added to the 
PDL file. SmartChart outputs are struc¬ 
ture charts, a nesting tree file, and pro¬ 
gram source code. 

PowerPDL (formerly Prism Design 
Language) is a program design tool that 
performs two design functions. First, it 
translates the FreeFlow skeleton PDL 
file (pseudocode) into nesting trees used 
by SmartChart to create structure 
charts. Second, it generates formatted 
documentation from the PDL at any 
phase of design development. A Strip 
utility allows PDL embedded in the 
source code as comments to be auto¬ 
matically extracted when requested, 
allowing documentation upgrading dur¬ 
ing program maintenance. PowerPDL 


outputs are a PDL listing file and a 
nesting tree file. 

FastTask will expand the logical sys¬ 
tem model by including real-time sup¬ 
port. It helps simplify real-time system 
analysis and design tasks by mapping 
time-dependent behavior characteris¬ 
tics. A graphics editor allows the ana¬ 
lyst to map a state transition diagram. 
Tables and matrices are automatically 
created from the data. FastTask out¬ 
puts are state transition diagrams, state 
tables, state/event matrices, and from- 
state-to-state matrices. 
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Recommendations 

Each product offers the potential to 
improve software development produc¬ 
tivity, yet each has unique features. The 
highly important feature of consistency 
checking is included in all four products. 
And each now offers the basic diagram¬ 
ming, dictionary, and specification¬ 
generating features. Of course, if the 
PC environment has already been set— 
IBM or Apple—then choices are 
reduced to two. 

In an IBM PC and compatible envi¬ 
ronment, the Visible Analyst Work¬ 
bench offers the flexibility of multiple 
and custom methodologies. It also 
offers the utility of a free-form 
diagramming tool. Teamwork/PCSA’s 
primary strength is its ability to export 
to Teamwork workstation products. 
And if Cadre Technologies’ EDIF stan¬ 
dardization proposal is widely accepted, 
the interchange may include the entire 
CASE world. 

In the Macintosh environment, 
Anatool offers excellent capability for 
the price. The Gane and Sarson style 
diagrams may be a limitation some 
users won’t be willing to accept. The 
standard English option for structured 
specifications is handy for many 
specification-related documentation 
tasks. Iconix PowerTools offers the 
most extensive life-cycle support, but at 
the highest price. With Version 2.0 and 
FastTask, it is the only one of the four 
products that explicitly offers support 
for real-time extensions. 

The current capabilities of these low- 
cost products is surprising. But anyone 
tracking low-cost CASE over the last 
two years can anticipate that the best is 
yet to come. 
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NEW PRODUCTS 


Hewlett-Packard expands portable PC line 


Hewlett-Packard has announced the 
first two members of a new family of 
portable personal computers based on 
Intel 8086-compatible CMOS micro¬ 
processors. According to the company, 
the HP Portable Vectra CS and the HP 
Portable Vectra CS Model 20 com¬ 
puters target office and sales profes¬ 
sionals who need both a desktop 
computer and a battery-powered 
portable. 

The HP Portable Vectra CS offers 
four internal I/O expansion slots, per¬ 
mitting the addition of increased mem¬ 
ory, communications devices, or 
peripherals. 

The Vectra CX provides two 1.44M- 
byte floppy disk drives, while the Vectra 
CS Model 20 has a 20M-byte hard disk 
drive and a 1,44M-byte floppy disk 
drive. The 3/-inch drives are compatible 
with IBM Personal System/2 disks and 
industry-standard 720K-byte disks. 

Both systems come with 640K bytes 
of memory. Up to 6M bytes of EMS 
RAM can be added to the Vectra CS 
and up to 4M bytes can be added to the 
Model 20. 

The 12-inch-diagonal liquid-crystal 
display is removable, so the system can 
be connected to an external monitor for 
use as a desktop PC. The display offers 
640 x 400 resolution. 

An HP Portable Vectra CS costs 
$2495. The Model 20 costs $3595 and is 
scheduled for the first quarter of 1988. 

Hewlett-Packard has also announced 
a 24-wire, serial impact dot-matrix 
printer, with print speeds reputedly 
reaching 480 characters per second in 
draft mode and 240 cps in letter-quality 
mode. Resolution achieves up to 
180 x 360 dots per inch. 

According to the company, the Rug- 
gedwriter 480 has a 20,000-hour mean 
time between failures. The printer han¬ 
dles hand-fed sheets, z-fold paper, and 
automatic cut sheets. 

The Rugged writer 480 costs $1695. 



The Hewlett-Packard 
Ruggedwriter 480 
24-wire dot-matrix 
printer claims a mean 
time between failures 
of 20,000 hours. 
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The Hewlett-Packard Portable Vectra CS personal computer features two 3/-inch 
floppy disk drives that can hold 1.44M bytes. 
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Wang PC 240 offers new entry point to PC 200/300 Series 



Wang Laboratories has extended the 
PC 200/300 Series with the Professional 
Computer 240. The 80286-based PC 
240 is IBM PC-AT compatible, accord¬ 
ing to the company. The computer 
serves as a Wang VS workstation or as 
a stand-alone personal computer. 

The PC 240 comes in three configura¬ 
tions differing only in disk controller 
and disk storage options, with prices of 
$2125 for the single disk, $2325 for the 
dual disk, and $2895 for the hard disk 
configurations. 

The new system shares common ele¬ 
ments with the PC 200/300 Series, 
including the operating system, applica¬ 
tions, user interface, and hardware 
components such as monitors, key¬ 
board, option cards, and peripherals. 
The base system comes with 640K bytes 
of RAM on the system CPU card and 
includes the MS DOS 3.2 operating sys¬ 
tem and Microsoft Windows. 

According to the company, memory 
can be upgraded by adding Wang or 
industry-standard 16-bit expanded 
memory cards. The system supports up 
to one or two half-height disk drives. 

To employ the PC 240 as a Wang VS 
workstation, users can install the Wang 
Local Office Connection. The computer 
runs a range of communication soft¬ 
ware from Wang and third parties, 
according to Wang. 

The chassis includes three 16-bit and 
one 8-bit expansion slots. Maximum 
memory is 6M bytes of RAM. Available 
ports include one serial and one paral¬ 
lel, with two additional serial ports pos¬ 
sible through a synchronous/asyn- 
chronous communications card. 
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Microsoft updates Word with 

Microsoft has announced Word ver¬ 
sion 4.0 for the IBM PC and compati¬ 
bles and the IBM Personal System/2. 
According to the company, new fea¬ 
tures include increased speed, document 
management and retrieval, macros, and 
improvements to the user interface. 

A new toggle switch between text and 
graphics modes allows users to enter 
data in the text mode and toggle to 
graphics mode to see the text displayed 
on the screen as it will appear on the 
printed page. 

The macro functions can be created 


Wang Laboratories’ PC 240 serves as a Wang VS workstation or as a stand-alone 
PC. A member of the PC 200/300 Series, the computer is compatible with IBM’s 
PC-AT. 


improved document handling and speed 


using a record mode, and the more 
powerful macros can be edited from 
within Word. 

Summary sheets for each document 
and the ability to search for words and 
phrases reportedly streamline the docu¬ 
ment retrieval process. 

Other new features include redlining, 
a spreadsheet link, style-by-example 
style sheets, integration of the spelling 
checker, line drawing and paragraph 
borders, and additional hardware sup¬ 
port for printing. 


Word 4.0 costs $450. It includes both 
5'/,- and 3K-inch disks. Current regis¬ 
tered customers can upgrade for $75. 

A network version adds support for 
network printers and file servers, shared 
files, optional read-only access, cus¬ 
tomizable settings, and shared glos¬ 
saries and style sheets. Suggested retail 
prices are $750 for the Server Master 
Pack and $150 for each Workstation 
User Manual Pack. 
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Joint offering provides DECnet for Macintoshes 


Technology Concepts and Dove 
Computer offer a jointly developed way 
to connect Apple Macintosh computers 
to Digital Equipment computers. A 
Macintosh user can communicate with 
DEC systems on a Decnet Phase IV 
Ethernet network using Community 
software from Technology Concepts 
and a Fastnet Ethernet controller from 
Dove Computer. 

Community is scheduled for the 
fourth quarter of 1987. It will include 
virtual terminal and VT220 emulation 
(VT240 optional), task-to-task commu¬ 
nications, remote file transfer and 
access, remote file access services, and 
network management. 

Community is a portable implemen¬ 
tation of Decnet, according to Technol- 


Unisys claims that the new A Series 
Smallframe packs 48-bit, mainframe 
processing power into a minicomputer¬ 
sized cabinet. The family features three 
deskside office systems, beginning with 
an entry-level computer that can grow 
three times in cabinet to a midrange 
mainframe, according to the company. 
The Smallframe cabinet measures 18^ 
by 29 by 29 inches. 

The entry-level A 1 can be expanded 
to the intermediate A 4 and upgraded 
again to the A 6 midrange mainframe. 
The system unit houses the central 
processor, main memory, data commu¬ 
nications processor, maintenance sub¬ 
system, and up to 500M bytes of disk 


Intel Scientific Computers has 
announced its second generation hyper¬ 
cube, the iPSC/2 family of concurrent 
supercomputers. According to the com¬ 
pany, hardware and software develop¬ 
ments make the family easier to program 
and up to ten times faster than first 
generation hypercubes. 

The new systems come in configura¬ 
tions from 16 to 128 processing nodes, 
with up to a gigabyte of memory. Vec¬ 
tor concurrent iPSC/2 VX systems 
come in configurations of up to 64 
nodes, with a vector arithmetic acceler¬ 
ator at each node. Peak performance 
reputedly reaches more than 400 
Mflops. 

Each node features a four-MIP 80386 


ogy Concepts. Fastnet is a communi¬ 
cations engine based on a 68000 CPU. 

A Macintosh with Community and 
Fastnet will reportedly be able to com¬ 
municate with Digital Decnet Phase IV 
products running on VMS, Ultrix, and 
RSX-11M operating systems, and other 
Community systems. 

Apple systems supported include 
Macintosh Plus, Macintosh SE, Macin¬ 
tosh II, and Macintosh 512 with an add¬ 
on SCSI adaptor running Macintosh 
system 3.3 or greater and Finder 5.4 or 
greater. 

In single quantities, Community costs 
$400 and FastNet, $899. 
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storage. 

The A 1, A 4, and A 6 prices start at 
$25,000, $55,000, and $145,000, respec¬ 
tively. Typical fully configured system 
range from $59,000 to $300,000. 

According to the company, the 
Smallframe systems incorporate CMOS 
gate arrays, VLSI devices, and one- 
megabit DRAMs. They also include the 
industry-standard SCSI and the 
MCP/AS operating system. They sup¬ 
port communications network gate¬ 
ways, remote diagnostics, and 
unattended operation via a remote 
telecommunications link. 
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and 80387. Surface-mounted one- 
megabit DRAM modules provide from 
one to 16M bytes of memory per node. 

According to the company, the 
iPSC/2 features Direct-Connect rout¬ 
ing, based on Intel and DARPA 
cosponsored research at Caltech. This 
routing reportedly enables the program¬ 
mer to ignore the hypercube intercon¬ 
nect and use all nodes of the concurrent 
machine as if each were connected to all 
others. 

Volume shipments are scheduled for 
January 1988. Existing customers can 
upgrade their current systems. Prices 
range from $200,000 to $2 million. 
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Electronic publishing 
software runs on Mac II 

Interleaf has announced Interleaf 
Publisher document-processing soft¬ 
ware for the Apple Macintosh II per¬ 
sonal computer. The software already 
runs on engineering workstations. 

According to the company, the soft¬ 
ware particularly suits the creation of 
long, complex documents. It automates 
page layout for multipage documents 
and integrates word processing and 
graphics creation. 

The Interleaf product reportedly ena¬ 
bles the Macintosh II to be networked 
to engineering workstations, including 
Sun Microsystems, Digital Equipment, 
Apollo Computer, and IBM RT sys¬ 
tems. Since Interleaf runs on these sys¬ 
tems, they and the Macintosh can share 
documents. The program makes use of 
Apple networking capabilities, so that 
changes in one copy of a document are 
reflected in all linked copies elsewhere 
on the network. 

Interleaf Publisher costs $2495. It 
uses a Macintosh II with five megabytes 
of RAM and a 40M-byte hard disk. A 
complete system, including hardware, 
software, and one year’s support, costs 
$10,900. With an Apple LaserWriter 
Plus printer, the system costs $16,500. 
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Manufacturing software 
targets IBM System/38 

Xerox Computer Services has tar¬ 
geted the IBM System/38 with the 
Xerox Business Management Sys¬ 
tem/38. The Manufacturing software 
system features nine software modules 
for planning and controlling manufac¬ 
turing, financial, and distribution oper¬ 
ations. 

Specifically, the modules cover pur¬ 
chasing, accounts payable, accounts 
receivable, order processing, inventory 
management, payroll and personnel 
management, bill of material/cost/ 
routing, general ledger, and manufac¬ 
turing resource planning. 

The software is reportedly written in 
the IBM System/38 programming lan¬ 
guage, RPG III. It is a closed-loop 
MRP II system, according to the 
company. 

The applications can be purchased 
separately or as an integrated system. 
Prices start at $10,000. 
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Unisys’ Smallframe puts mainframe power in 
minicomputer package 


Intel speeds up second generation hypercubes 
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IMC 80286-based portable weighs 20 pounds 


IMC International offers the Porta¬ 
ble Office, an IBM PC-AT-compatible, 
Intel 80386-based portable computer. 
Standard configuration includes a 40M- 
byte hard disk, a 1.2M-byte floppy 
disk, 640K bytes, parallel and serial 
ports, three long and three short expan¬ 
sion slots, and a Supertwist backlit 
LCD screen. 


The system clock can be set at 6 or 10 
MHz. The real-time clock has a battery 
backup. The operating system is Phoe¬ 
nix or Award BIOS. 

The system weighs approximately 
twenty pounds and costs $3295. 
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Ready Systems’ CARDtools promote computer-aided 
real-time design 


Ready Systems has announced 
CARDtools, which the company claims 
use a new technology: computer-aided 
real-time design. According to the com¬ 
pany, CARDtools maintain documenta¬ 
tion during all phases of software 
development and maintenance, and 
offer support for real-time embedded 
computer systems, such as real-time 
performance verification. 

Specific tools include 

• Taskbuilder, a graphics editor and 
analysis tool for designing dataflow 
diagrams and modeling the mul¬ 
titasking architecture; 

• Real-Time Performance Verifica¬ 
tion, a tool that performs critical- 
path timing analysis on the mul¬ 
titasking architecture specified 
using Taskbuilder; 

• Software-Hardware Interface Facil¬ 
ity, which prompts the designer for 


complete, detailed specification of 
signals and data that interface 
between software and hardware; 
and 

• Control Maps Builder, a hierarchi¬ 
cal decomposition facility that 
includes data types definition, data 
types, package definition, and Pro¬ 
gram Design Language facilities. 

The CARDtools are integrated 
through a common, centralized data¬ 
base called CARDbus, from which 
documentation is automatically 
generated. 

CARDtools are available for VAX- 
station 2000/VMS, VAX/VMS using 
VT100, and IBM PC host environ¬ 
ments. Prices range from $10,000 to 
$60,000 depending on the tools package 
and host. 
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Gateway interconnects disparate LANs 


Bridge Communications has 
announced the GS/l-IP Gateway 
Server, which interconnects disparate 
LAN types—Ethernet, broadband, and 
token ring—across commercial X.25 
networks. 

The internetwork router can be con¬ 
figured with any of three network 
options: coaxial or fiber-optic cable- 
based lOM-bit-per-second Ethernet 
(IEEE 802.3), Bridge five-megabit-per- 
second CSMA/CD broadband, and 
four-megabit-per-second token ring 
(IEEE 802.5). Its CCITT X.25 interface 
supports 48 virtual circuits over eight 
physical lines. 

The GS/l-IP also allows network 
users to communicate with TCP/IP- 
based hosts directly connected to the 
X.25 network. 

The GS/l-IP costs $10,500 plus 
$2000 for a software license. It includes 
an X.25 interface and one LAN inter¬ 
face (Ethernet, broadband, or token 



Bridge Communications’ GS/l-IP 
network router connects disperse 
TCP/IP-based LANs via X.25 public 
or private data networks. 


ring). Additional interfaces (up to four) 
cost $2500 each. 
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DSM manages Nonstop 
system networks 

Tandem Computers has announced 
Distributed Systems Management soft¬ 
ware that aids in the management of 
large, dispersed networks of Nonstop 
systems. According to the company, the 
DSM software allows the consolidation 
of previously isolated systems and net¬ 
work management functions. 

The company offers the DSM 
products in an Operations Management 
package that includes four modules, 
scheduled for the fourth quarter of 
1987. 

Viewpoint is an operations console 
facility that can be used as a status 
monitor, even display, and command 
and control center for DSM. 

Measure collects and examines per¬ 
formance statistics. 

Network Statistics Systems provides a 
network-wide view of performance 
data. It collects, monitor, and reports 
real-time network statistics on Nonstop 
systems and lines in a Tandem network. 

Distributed Name Service provides a 
single source for storing and retrieving 
information about multiple names used 
to identify system and network com¬ 
ponents. 

The OM package has an initial license 
fee of $3200 and a monthly license fee 
of $320 per Nonstop VLX or TXP sys¬ 
tem. The initial license fee is $1600 and 
the monthly license fee is $150 per Non¬ 
stop EXT25, EXT10, or CLX system. 
The four products may also be purchased 
separately. 
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Ashton-Tate networks 
Multimate Advantage II 

Ashton-Tate offers a local area net¬ 
work version of its word processor, 
Multimate Advantage II. The Advan¬ 
tage II LAN Pack, which includes one 
server and five workstation modules, 
costs $1495. Additional workstation 
modules are $150 each. The product 
comes with either 5X- or 3K-inch disks. 

LAN features include file locking, 
document sharing, and individual cus¬ 
tomization of system defaults. 

The LAN operates on IBM PC LAN 
(PC Net and Token Ring), Novell 
Advanced Netware 86 and 286, and 
3Com3 + . It also runs on LANs that 
use PC-DOS 3.1-compatible operating 
systems. 
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Codex 9800 manages 
networks 

Codex has announced the Codex 
9800 Series Integrated Network 
Management System. According to the 
company, the product’s integrated, 
open architecture enables users to man¬ 
age modems and multiplexers and per¬ 
form management applications 
concurrently from a single workstation. 

The Codex 9800 is based on the 
Apollo Domain Series 3000 engineering 
workstation. It reputedly combines a 
graphically-oriented method of con¬ 
figuring, monitoring, and controlling 
devices in a network with an integrated 
database and integrated application 
tools for event, fault, performance, and 
configuration management. 

The Codex 9800 features windowing, 
color graphics, and a mouse. Security 
features reputedly prevent unauthorized 
use of the system. 

The Codex 9800 will be available for 
shipment in January 1988 with a base 
price of $61,900. 
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Bridge Communications Secure CS/50 Communications Server (front) and Secure 
NCS/AT Network Control Station (back) provide data security and access control 
for network users and resources in sensitive environments. 


PC-based publishing links 
and manages documents 


Bestinfo has announced the Docu¬ 
ment Management System, a personal- 
computer-based electronic publishing 
system that the company says links and 
manages the document production 
process within corporate environments. 
As many as 100 PCs can reputedly be 
linked with DMS through a local-area 
network. 

The DMS includes four workstations: 
The Writer’s Workstation, The Editor’s 
Workstation, The Illustrator’s Work¬ 
station, and The Production Work¬ 
station. 

Specific features reportedly include 
pagination for handling floating pic¬ 
tures, tables, and footnotes on mul¬ 
ticolumn pages; automatic numbering 
of sections, pictures, and footnotes; 
integrated drawing tools; and 
Tablemaster, a feature that enables 
users to import tables from spread¬ 
sheets, databases, and word processors. 

DMS runs on the IBM PC-XT, PC- 
AT, or compatible, and the Compaq 
Deskpro 386 or compatible. In a LAN, 
DMS supports Novell’s Netware. 

Prices range from $595 to $8000 for 
the software to around $4000 to $17,000 
for workstations. 
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LAN family provides encryption 


The Government Products Division 
of Bridge Communications has 
announced a family of local area net¬ 
work products offering data encryption 
and based on Transmission Control 
Protocol/Internet Protocol. 

The Secure CS/50 Communications 
Server and Secure NCS/AT Network 
Control Station are the first two mem¬ 
bers of a family of LAN products the 
company designed to provide data secu¬ 
rity and access control for network 
users and resources in sensitive or con¬ 
trolled environments. They are based 
on the Department of Defense’s 
TCP/IP protocol set. 

The Secure CS/50 server supports 
two asynchronous terminals, printers, 
modems, host ports, or personal com¬ 
puters. The Secure NCS/AT is an IBM 


PC-AT Xenix-based network manage¬ 
ment station that allows centralized 
control and monitoring of LAN- 
attached computer resources. 

Both products reportedly provide 
user authentication, security profiles, 
access controls, data encryption, and 
audit-trail information. All TCP session 
data are encrypted using the Data 
Encryption Standard encryption algo¬ 
rithm. Administrative and audit-trail 
information transferred to and from the 
Secure NCS/AT is also encrypted under 
a public key encryption system. 

The Secure CS/50 costs $2195 and 
the Secure NCS/AT, $17,900. An 
NCS/AT upgrade kit is $6250. 
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Products help PS/2 communicate with minis, 
mainframes 


IDEAssociates offers two emulation 
boards that enable IBM Personal Sys¬ 
tem/2 computers to communicate with 
other machines. The Ideacomm 
5250/Remote MC emulation board con¬ 
nects remote PS/2 Models 50, 60, and 
80 to IBM System 34/36/38 minicom¬ 
puters through a synchronous modem. 
The Ideacomm 3278/MC emulation 
board provides PC-to-mainframe com¬ 
munications for the same PS/2 models. 

The Ideacomm 5250/Remote MC 
reputedly emulates the functions of the 
5251 Model 12 and 5294 cluster con¬ 
trollers to provide connection to the 
System 3X. It also supports the text- 
entry-assist feature of the 5294 con¬ 
troller. The product supports nine con¬ 
current host sessions. The card and 
software cost $795. 

The Ideacomm 3278/MC reputedly 


Puma Software has announced 
Matrix Workshop, a command-driven 
program for matrix analysis and linear 
algebra solutions that runs on the Apple 
Macintosh. Matrix Workshop is a 
Macintosh implementation of the main¬ 
frame program Matlab. 

The software consists of over 80 
functions, including matrix inversion, 
determinant, norm, rank, and eigen¬ 
values and eigenvectors. It can calculate 
transcendental functions of a scalar, 
vector, or matrix. It can also determine 
roots of polynomials, perform a Fast 
Fourier Transform, convert polar to 
rectangular and vice versa, and create 
linear and logarithmic plots of data. 
Gaussian elimination and singular value 
decomposition functions are provided 


Austec has announced a Cobol appli¬ 
cations development environment called 
RM/Master Cobol. The product 
includes an ANSI 74 Cobol compiler 
based on the company’s Acecobol tech¬ 
nology, plus a text editor, screen, 
painter, report program generator, and 
data dictionary. 

For program execution, RM/Master 
Cobol provides a menu development 
system and a bridge that provides a 
standard interface between applications 
software and dissimilar hardware and 


allows the PS/2 Model 50, 60, or 80 to 
duplicate the functions of an IBM 3278 
or 3179 terminal through a local coaxial 
connection to an IBM 3174, 3274, or 
3276 cluster controller. According to 
the company, it provides seven-color 
support for IBM 3179 terminal emula¬ 
tion and also emulates IBM 3278 
Models 2, 3, 4, and 5. The Model 5 ter¬ 
minal emulation reportedly allows users 
to access applications with wider 
layouts. 

The 3278/MC has two interface 
options: native Idea mode and IRMA 
mode. 

The Ideacomm 3278/MC includes an 
interface board, and emulation and file 
transfer software for $995. 
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for system solutions and curve fitting. 

An option permits users to write exec 
files and user functions. Exec files can 
be created with any text editor or word 
processor, according to the company. 

The 2D graphics routines of the pro¬ 
gram can plot multiple functions of a 
single variable and plots can be printed 
or saved to disk. The inputs and out¬ 
puts of Matrix Workshop sessions can 
be copied to the clipboard for use by 
other Macintosh application programs. 

Matrix Workshop runs on a Macin¬ 
tosh personal computer with a mini¬ 
mum of 512K bytes. It is written in 
MS-Fortran and costs $295. 

Reader Service 52 


operating systems based on Austec’s 
Acebridge. 

The environment also includes a 
package of optional program generator 
extensions. 

RM/Master Cobol is available under 
Unix for the NCR Tower, with versions 
for PC-DOS and MS-DOS. Prices 
depend on the operating system and 
hardware configuration. 
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Aldus offers Pagemaker 
templates 

Aldus has announced Pagemaker 
Portfolio: Designs for Business Com¬ 
munications, a package of 18 templates 
for the creation of business documents. 

The package comes with predesigned 
page formats for proposals, memos, 
overhead transparencies, reports, hand¬ 
books, and business plans. 

The package is available for the 
Apple Macintosh and IBM PC to run 
on Postscript-compatible output 
devices, with another version available 
for PCL-compatible printers. 

Designs for Business Communica¬ 
tions is the second in the Pagemaker 
Portfolio template series. It retails for 
$99. 
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Imaging system achieves 
600 dots per inch 

Varityper’s VT600 laser printer reput¬ 
edly achieves a resolution of 600 dots 
per inch both vertically and horizon¬ 
tally. It comes with a Postscript raster 
image processor that employs Adobe 
Systems’ M68020-based Atlas board 
with six megabytes of RAM. The basic 
system includes 13 typestyles, and addi¬ 
tional Postscript-compatible typestyles 
can be downloaded to the VT600’s 
20M-byte Winchester disk. 

The imaging system’s xerographic 
printing engine has a rated speed of 10 
pages per minute, according to the com¬ 
pany. It handles plain paper (16- to 
24-pound) and letter, legal, A4, and B4 
size paper. It also handles labels and 
transparencies, manually. 

The VT600 supports Appletalk as 
well as Centronics parallel and RS-232 
communications. 

The VT600 plain-paper laser printer 
costs $13,500. 
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Varityper’s VT600 claims a resolution 
of 600 dots per inch and features plain- 
paper output. 


Matrix analysis software runs on the Macintosh 


Software development tools aid Cobol applications 
development 
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Bridge upgrades SNA gateway 


Bridge Communications has upgraded 
the Communications Server/l-SNA. 

The enhanced version incorporates the 
MC68020 32-bit microprocessor, which 
reputedly allows networked devices to 
share up to 48 host sessions. The upgraded 
CS/l-SNA supports both the Transmis¬ 
sion Control Protocol/Internet Pro¬ 
tocol and Xerox Network Systems 
protocol sets. 

According to the company, the 
CS/l-SNA allows LAN-attached users 


to participate in an IBM 3270 SNA 
environment. It supports three LAN 
types: Ethernet, IEEE 802.3, with coax¬ 
ial or fiber-optic cable; token ring, 

IEEE 802.5; and Bridge Broadband. 

The CS/l-SNA costs $10,500 plus a 
$1000 software fee. A $5000 hardware 
and software upgrade kit is available to 
owners of the original Ethernet 
version. 
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Bridge Communications’ CS/l-SNA gateway lets PCs, 3270-type displays, and 
ASCII terminals and printers operate in an IBM 3270 SNA environment via Ether¬ 
net, token ring, and broadband LANs. 


Communications processor gives more throughput 


Amdahl claims that its new genera¬ 
tion of communications processors give 
users up to 80 percent more throughput 
than previous models. The new systems 
serve as front-end processors or remote 
concentrators in data communications 
networks. They run standard 3725 
ACF/NCP software, according to the 
company. 

The Model 4725-40 reputedly 
achieves about 80 percent higher 
throughput than Amdahl’s earlier 
Model 4705E. The Model 4725-30 
reputedly achieves about 20 percent 
higher throughput. 

The 4725 Series can reportedly be 
intermixed in networks with Amdahl’s 
4705 and 4705E as well as IBM’s 3725, 
3720, and 3705 communications con¬ 
trollers. 

The new models support up to three 
megabytes of memory. Each can report¬ 


edly accommodate 128 half- or full- 
duplex lines in the base frame and up to 
256 lines with an optional expansion 

Currently, the processor can be used 
with Amdahl’s Multistar T1 Multiplexer, 
with support planned for IBM’s 
Token-Ring. 

The 4725-40 is available now. The 
4725-30 is scheduled for the third quar¬ 
ter of 1988. 

Prices range from $71,500 for the 
Model 4725-30 with 512K bytes of main 
memory and two line attachment bases 
to $545,160 for a 4725-40 configured 
with six channel adapters, eight line 
attachment bases, 64 high-speed com¬ 
munications lines, three megabytes of 
main storage, and the optional expan¬ 
sion unit. 

Reader Service 57 


Hard disk subsystem is 
portable 

Tradewinds Peripherals has 
announced a portable hard disk sub¬ 
system called Traveldisk, which the 
company claims is the smallest, remova¬ 
ble, rugged portable hard disk sub¬ 
system available. It comes in three 
case models, all with capacities of 10 
22, 32, 49, 64, and 98 megabytes. The 
Model 3 is available for Tempest certifi¬ 
cation. 

The autoswitching feature reportedly 
allows the subsystem to tell whether 
there is another hard disk in the system. 
If so, Traveldisk makes itself a D:/ 
drive; if not, a C:/ drive. According to 
the company, if Traveldisk is a backup 
D:/ drive and the C:/ drive fails, it 
automatically takes over the main drive. 

Traveldisk works with IBM PC, PC- 
XT, PC-AT, 386, and PS/2 Model 30 
computers and compatibles. 

Security options are available to com¬ 
panies or government agencies with the 
appropriate clearances. 

Prices begin at $895, including card 
and cable. Additional bus extender 
cards cost $40 each. 
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Gateway connects PC LANs 
and mainframes 

Rabbit Software has announced Rab- 
bitgate, a data communications gateway 
that permits access to mainframes for 
local area networks of PCs and IBM 
PS/2 computers at speeds that reput¬ 
edly reach up to 56,000 bits per second. 

Rabbitgate includes a plug-in adapter 
board with software that provides con¬ 
current emulation of IBM SNA and 
BSC 3270 and 3770 remote communica¬ 
tions devices on the PCs in a LAN. 
According to the company, it also pro¬ 
vides a platform for future LU 6.2 
product releases. 

Rabbitgate reportedly supports Net¬ 
BIOS LANs, including 3Com, Novell, 
IBM, and so forth. It uses an 
80186-based coprocessor to offload 
gateway processing from the PC. Up to 
32 host sessions are provided for each 
gateway, and multiple gateways can be 
installed on the same LAN. 

Prices depend on the number of host 
sessions available. They start at $2395 
for a gateway configured for eight host 
sessions for any size LAN or number of 
users. 

Reader Service 59 
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1C Announcements 


Company, Model, Function _ Comments R.S. No. 


Advanced Micro Devices 
Am99C164, Am99C165, 
Am99C88H 
SRAMs 


Advanced Micro Devices 

Supernet 

LAN chip set 


Analog Devices 
AD7569 

Analog I/O port 


Chips and Technologies 

CS8245 

VGA chip set 


Gould Semiconductor 
S618839 

Shuffle/exchange chip 


Integrated Device Tech¬ 
nology 

IDT72401/03, IDT72402/04 

IDT72413 

FIFOs 

Signetics 

PCL473 

PLA 


Thomson Components 

TS1200 

EPROM 

Thomson Components 

TS1834 

CPU 


Western Digital 

WD42C22 

Hard disk controller 


Xilinx 

XC3020 

PGA 


Zoran 

VSP-325 

VSP 


CMOS static RAMs. Am99C164 and Am99C165 are organized as 16K x4 bits. Am99C88H 
is organized as 8K x 8 bits. All three come in standard and low-power versions and have 
access times down to 35 ns for commercial and 45 ns for military versions. Cost: in 100s, 
$25.50 for Am99C164 in a 22-pin plastic DIP; $28.30 for Am99C165 in a 24-pin ceramic 
DIP; and $20 for Am99C88H in a 28-pin ceramic DIP. 

A five-device chip set for local area networking using fiber-optic media. Implements the 
ANSI FDDI standard specifying 100 megabit-per-second operation. Consists of a buffer 
controller, data path controller, fiber-optic ring media access controller, transmitter, and 
receiver. Cost: $625 (100s). 

Combines an 8-bit ADC, 8-bit DAC, track-and-hold amplifier, buffer amplifier, and volt¬ 
age reference. Available in six grades over three temperature ranges. Comes in 24-pin plas¬ 
tic DIP, 24-pin cerdip, 28-terminal LCC, and 28-terminal PLCC. Cost: in 100s, prices start 
at $6 for JN, $9 for AQ, and $27 for SQ grades. 

Consists of two devices, a Video Graphics Array display controller (82C441) and bipolar 
VGA bus interface (82A442). Compatible with IBM’s VGA used in PS/2 Models 50, 60, 
and 80, and with EGA, CGA, Hercules, and MDA software. Comes in an 84-pin PLCC or 
100-pin flat-pack (82C441) and 68-pin PLCC (82A442). Cost: $40.50 (1000s). 

A 32-bit shuffle/exchange network chip for data manipulation. Has four levels of mul¬ 
tiplexing. Typical data fall-through speed of 15 ns, with switch configuration and output 
enables in 17 and 6 ns, respectively. Power dissipation of 150 mW. Comes in an 84-pin 
PLCC. Cost: $34.95 (1000s). 

Five 45-MHz FIFOs. IDT72401 and IDT72403 are 64-word X 4-bit FIFOs; IDT72402 and 
IDT72404 are 64-word x 5-bit FIFOs; and IDT72413 is a 64-word x 5-bit FIFO with flags. 

, Available in a variety of packages. Cost: in 100s, start at $15 for IDT72401/03 in plastic 
DIP; $23 for IDT72402/04 in plastic DIP; $30 for IDT72413 in plastic DIP. 


An ultraviolet erasable programmable logic device that offers up to 11 output pins, nine of 
them bidirectional. Features 24 AND and 22 OR gates. Has an input-to-output propaga¬ 
tion delay of 60 ns. Available in a 24-pin DIP quartz window package, windowless 24-pin 
plastic DIP, and PLCC. Operates over a temperature range from 0°C to 70°C. Cost: $6.85 
(100s). 

A one-time-programmable 256-bit EPROM for smart card applications. Features an 8-pin 
serial I/O. Security features include 96 bits of memory that can be protected against writ¬ 
ing. Available in a variety of packages. Cost: $0.96 per die in wafer form (10,000s). 

Targets smart card applications. Features an 8-bit CPU, 3K bytes of ROM, 4K bytes of 
EPROM, 76 bytes of RAM, and a 6-pin serial I/O. Available in a variety of packages, but 
designed to be embedded into standard plastic cards. Cost: $8.25 per die in wafer form 
(10,000s). 

Integrates a disk controller, buffer manager, interface, and error correction. Designed for 
IBM PC-XT and PC-AT and SCSI interfaces. Can translate data into RLL 2, 7, MFM, 
and NRZ data-encoding schemes. Comes in an 84-pin PLCC or as a Jedec flat pack. Cost: 
around $50 (1000s). 

A programmable gate array that includes the equivalent of 1800 to 2400 two-input NAND 
gates, a 1.2-micron CMOS process, and a 40-MHz system clock rate. Consists of three 
user-programmable elements: I/O blocks, configurable logic blocks, and interconnections. 
Available in volume by the end of 1988. Cost: $20 (10,000s). 

A 32-bit vector signal processor that uses IEEE floating-point arithmetic. Implements a 
high-level instruction set, including digital filters, matrix operations, FFTs, polynomial 
expansions, etc. Available in sample quantities second quarter 1988. Comes in an 84-pin 
PGA. Cost: around $100 in OEM quantities. 
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Company, Model, Function Comments R.S. No. 


Avalon Computer Systems 
AP/24 

Coprocessor 

An 80386-based Unibus circuit board to speed up VAX-based scientific and numeric pro- 135 

grams. Contains 64K-byte cache memory. Runs at 3.5 to 4 MIPS. AP/24 software sup¬ 
ports VMS, Ultrix, BSD Unix, and AT&T System 5 Unix. Cost: $11,900; $13,900 with 
floating-point accelerator. 

Cardiff Peripherals 

Classic Series 

Hard disk drives 

A series of 53M-, 80M-, and 127M-byte hard disk drives with 20-ms average seek time, 7W 136 
typical power consumption, and a proprietary track-following positioning mechanism. Will 
be offered with ESDI, SCSI, and ST506/412 interfaces. Production scheduled for second 
quarter 1988. No prices given. 

Ciprico 

Rimfire 3400 

ESDI controller 

An intelligent VMEbus ESDI controller with a disk serial rate up to 20 MHz and block 137 

transfer capability of'30M-bytes per second in burst mode. Features an 80186 processor 
managing a 512K-byte cross-track lookahead cache. Supports 8-, 16-, and 32-bit VMEbus 
data transfers. No price given. 

Data Business Systems 
Invader-286 

Multiprocessor board 

A multiprocessor board that allows the IBM PC-AT to support up to 32 workstations. 138 

Acts as a master CPU or slave user. Plugs into a 16-bit expansion slot. Supports DOS 3.3. 
Controlled by the company’s software, Multiprocessor Supervisor 2. Cost: $1395. 

Heurikon 

HK68/V2F 

VME engine 

A 68020-based VME engine with 20-MHz, zero wait-state read, one wait-state write opera- 139 
tion. Up to 4M bytes of DRAM with parity, optional 68881 floating-point coprocessor, up 
to 128K bytes of EPROM, 128 bytes of nonvolatile RAM, and one RS-232 serial port. 

Cost: in 100s, $1495; $2395 for no wait-state version. 

IDEAssociates 

Ideamax 30 

Memory board 

A memory board for the IBM Personal System/2 Model 30. Provides up to 8M bytes of 140 

LIM EMS. Also operates on the IBM PC and PC-XT. Features a dynamic wait-state 
design. The board’s software enables users to create a RAMdisk. Cost: starts at $485 for 

512K bytes. 

IDEAssociates 

Ideamax/MC, 

Supermax/MC 

Memory, multifunction 
boards 

Both target IBM Personal System/2 Models 50, 60, and 80. Ideamax/MC has 12M bytes of 141 
memory. Supermax/MC has up to 8M bytes of memory, a serial port, and a parallel port. 

The software enables creation of a RAMdisk. Cost: $495 for Ideamax/MC with 512K 
bytes; $645 for Supermax/MC with 512K bytes. 

MiniScribe 

8425F,8438F 

Winchester drives 

Part of the Fast Series. Both feature 40-ms access time with formatted storage capacities of 142 
21.4M bytes (8425F) and 32.7M bytes (8438F). The drives are based on the 8425 and 8438 
disk drives. They have a mean-time between failure of 20,000 hours. No prices given. 

Qualogy 

QLC-1000 

Optical disk controller 

An optical disk controller board for Q-bus systems. Compatible with Digital Equipment 143 

hardware and software. Emulates the TK-50 tape drive in the Q-bus system, and uses the 
same commands as the TK-50. Firmware handles translation functions. Cost: $1995. 

Storage Technology 

4380 Subsystem 

DASD subsystem 

A solid-state DASD subsystem that emulates the IBM 3880/3380 DASD subsystem. Fea- 144 

tures capacities from 48M bytes to 3G bytes. Comes standard with dual ports; a second 
control unit results in quad ports. Cost: $204,100 for a minimum system; $971,000 for a 
quad-port with two battery backup units. 

Tecmar 

MicroRAM 

Memory board 

An expansion board for the IBM Personal System/2 Models 50, 60, and 80. Compatible 145 

with LIM EMS 4.0. Available in 512K-, 1M-, 2M-, and 8M-byte models, with or without 
serial ports. Cost: $495 (512K bytes) to $5495 (8M bytes with two serial ports). 

Vermont Microsystems 
Cobra 

Graphics processor 

Draws images at the rate of 80,000 clipped vectors per second, with 1024 x 800 resolution, 146 

16 to 256 simultaenous colors from a palette of up to 16.7 million, single-screen operation, 
and support for major graphics applications. Cost: $2995 for 16-color, 4096 palette; $3795 
for 256-color, 4096 palette; $4195 for 256-color, 16.7 million palette. 
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From books on artificial intelligence to conferences on design automation, the Computer 
Society has the information you want and the balance between theory and practice you need. 

We invite you to join us and receive these benefits: 


XjLn automatic subscription to 

COMPUTER Magazine 

This authoritative yet readable 
monthly brings you industry surveys, 
tutuorials, and application perspec¬ 
tives across the breadth of the 
computer field—from theory to 
practice, and every step in between. 



T 

JLhe opportunity to work shoulder-to- 
shoulder with experts 

in one or more of our standards working groups 
(we’ve got more than 80 now!) to develop draft 
standards, which after approval, become IEEE 
standards used throughout the world. (The Computer 
Society is unique in offering its members the 
opportunity to develop computer-related standards.) 


l>ow member rates on other Computer 
Society magazines and transactions 

Our magazines provide a practical application- 
oriented treatment of the leading edge of computer 
technology and our transactions provide the more 
analytical and theoretical base—the perfect balance 
between theory and practice. 


JL articipate in one or more of our 33 
technical committees— 


networks of professionals with common interests in 
computer hardware, software, and applications. 
Technical committee programs are determined by 
the membership. Some are more theoretical; others 
are more applied. 



Discounts on conference registration fees 

Choose from more than 100 worldwide annually, 
from large applications-oriented conferences to 
small workshops, and a range of theory and practice 
for every interest. 

THE COMPUTER SOCIETY VW. THE INSTITUTE OF ELECTRICAL AND 

OF THE IEEE Sf, ELECTRONICS ENGINEERS, INC. 


































Membership Application 


THE INSTITUTE OF EL 


ELECTRONICS ENG 


HOW TO JOIN 


Membership dues and publication subscriptions are annualized to December 31. 
Pay the full-year fee if application is mailed September 1-February 29. 

Pay the half-year fee if application is mailed March 1-August 31. 


COMPUTER SOCIETY ONLY (affiliate membership). 

* You are eligible if you are seriously interested in any aspect of the 
computer field or if you are a member of one of the affiliate 
societies listed below. 

(Check all applicable societies.) 


[ COMPUTER SOCIETY MEMBERSHIP FOR 
IEEE MEMBERS. If you are presently an IEEE member, you 
may join the Computer Society for a nominal amount. (Complete 
only shaded area of application.) 


Affiliate Societies 


n American Institute of Aeronautics and 
Astronautics (AIAA) 

| 0 American Institute of Physios (AIP) 

[ 0 American Mathematical Society (AMS) 
f 0 American Society of Mechanical Engineers 
O Association for Computing Machinery (ACM) 
istralian Computer Society 

□ British Computer Society 

0 Data Processing Management Association 
(DPMA) 

□ Information Processing Society of Japan (IPSJ) 

□ Institute of Electronic, Information and 

t Communication Engineers (IEICE) of Japan 

□ Institution of Electrical Engineers (IEE-UK) 


Mar 1-Aug 31 Sept1-Feb29 

□ $19.50 □ $39.00 


□ Mathematical As 

□ National Association of Accountants 

□ Operations Research Society of America 
(ORSA) 

□ Society of Aircraft Materials and Processes 
(SAMPE) 

□ Society of Automotive Engineers (SAE) 

□ Society for Industrial and Applied 
Mathematics (SIAM) 

□ Society for Computer Simulation (SCS) 

□ Society for Photo-Optical Instrumentation 
Engineers (SPIE) 

□ The Computer Society of the Republic of 
China (Taiwan) 


IEEE Member Number _ 


Mar 1-Aug 31 Sept1-Feb29 

□ $7.50 □ $15.00 


COMPUTER SOCIETY AND IEEE.* In addition to your 
* Computer Society benefits, you'll receive many IEEE privileges 
and benefits. You are eligible if your technical interests are in 
computer science and engineering, the electrical and electronics 
fields, or related fields. Your entry membership grade will be 
determined by your level of participation, contributions, education 
and/or experience in those fields. 


OPTIONAL PUBLICATIONS 

4 Whichever membership option you chose, you are now eligible to 
subscribe at low member rates to these periodicals. 

Half-Year Full-Year 
& Mar TAug 3t Sept TFeb 29 

□ $9.50 □ $19.00 
□ $10.00 O$20 

□ $ 6.00 n $12 

□ $ 9.00 □ $18 
□ $ 8.50 n$17 
□ $ 9.00 n$18 


IEEE Computer Graphics & Applications (3061)... 
IEEE Design and Test (3111) 

IEEE Expert (3151). 

IEEE Micro (3071). 

IEEE Software (3121). 

Transactions on Computers (1161) 

Transactions on Pattern Analysis and 

Machine Intelligence (1351). 

Transactions on Software Engineering (1171). 


Half-Year 


Residence 

United States. 

Canada. 

Europe, Africa, Middle East... 

Asia, Pacific. 


it 1-Feb 29 

□ $41.00 □$82.00 
. □ $38.50 □ $77.00 

,. □ $39.00 □ $78.00 

.. □ $33.50 □ $67.00 

.. □ $34.50 □ $69.00 


□ Check or Money Order 
(payable to the IEEE) 

□ Visa D Master Card 


□ American Express 


’ACM members who join both IEEE and the Computer Society 
are entitled to a deduction of $5 off the full-year rate; $2,50 off the half-year ra 


Credit Card Number 


STUDENTS! ► 


Expiration Date 

ss and benefits. Call or send 
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CAREER OPPORTUNITIES 


RATES: $12.00 per line, $120 minimum charge 
(up to ten lines). Average six typeset words 
per line, nine lines per column inch. Add $10 
for box number. Send copy at least six weeks 
prior to month of publication to: Heidi Rexoi 
Marian Tibayan, Classified Advertising, 
COMPUTER Magazine, 10661 Los Vaqueros 
Circle, Los Alamitos, CA 90720. 

In order to conform to the Age Discrimina¬ 
tion in Employment Act and to discourage 
age discrimination, COMPUTER may reject 
any advertisement containing any of these 
phrases or similar ones: “...recent college 
grads...,” “...1-4 years maximum experi¬ 
ence...,” “...up to 5 years experience...," or 
"...10 years maximum experience.” COM¬ 
PUTER reserves the right to append to any 
advertisement, without specific notice to the 
advertiser, “Experience ranges are sug¬ 
gested minimum requirements, not maxi- 
mums.” COMPUTER assumes that, since 
advertisers have been notified of this policy 
in advance, they agree that any experience 
requirements, whether stated as ranges or 
otherwise, will be construed by the reader as 
minimum requirements only. 


THE UNIVERSITY OF TEXAS AT DALLAS 

The University of Texas at Dallas School of 
Engineering and Computer Science is seeking 
applicants for tenure track faculty positions at 
all levels. Areas of primary focus are VLSI circuit 
design, switching systems, digital communica¬ 
tions, computer architectures, computer and com¬ 
munications networks, computer aided engineer¬ 
ing and manufacturing science. 

A Chair in Telecommunications is available, on a 
visiting or permanent basis, to nationally recog¬ 
nized leaders. 

Responsibilities will include development of 
sponsored research, direction of M.S. theses 
and Ph.D. dissertations, instruction of under¬ 
graduates and interaction with local high- 
technology industries. Opportunities for joint 
University-Industry research projects and con¬ 
sulting are excellent. 

A Ph.D. in engineering or a similar discipline is 
required. Applicants for full or associate pro¬ 
fessor must have a demonstrated record of 
scholarly productivity and ability to attract 
research sponsorship. 

Applications and nominations should be refer¬ 
red to: 

Academic Search #702 

The University of Texas at Dallas 

P.O. Box 830688 

Richardson, TX 75083-0688 
A resume with a list of five references should be 
included. Applications from women and minor¬ 
ities are especially welcome. Indication of sex 
and ethnicity for affirmative action statistical 
purposes is requested, but not required. Non 
U.S. citizens must indicate visa status. The 
search will remain open until all positions are 
filled. 

Inquiries should be referred to Dr. B. E. Cherring- 
ton, Dean of the School of Engineering and Com¬ 
puter Science. (214-690-2974). 

The University of Texas at Dallas is an Affir¬ 
mative Action/Equal Opportunity Employer. 


UNIVERSITY OF CALIFORNIA AT DAVIS 

The Computer Science Division of the University 
of California at Davis invites applications from 
highly qualified individuals for several tenure- 
track positions. The Division is especially in¬ 
terested in senior candidates with research 
strengths in the fields of computer architecture, 
networks, and VLSI design. Outstanding can¬ 
didates in other fields will also be considered. 
Rank and salary will be commensurate with 
qualifications. In addition to teaching com¬ 
petence, applicants must have a distinguished 
research record. 

The Division of Computer Science is an indepen¬ 
dent unit within the Department of Electrical 
Engineering and Computer Science. Its interests 
cover the mainstream areas of computer sci¬ 
ence, including artificial intelligence, computer 
architecture, computer systems design, data¬ 
base systems, computer graphics, computer 
security, fault tolerant computers, networking, 
numerical analysis, program specification and 
verification, operating systems, performance 
evaluation, robotics, software engineering and 
theoretical computer science. Current research 
strengths and facilities exist in the areas of com¬ 
puter graphics, theory, computer systems 
research, image processing, and robotics. 

The Division is in a period of building and 
growth, with the aim of becoming one of the 
leading computer science departments in the 
nation. The department administers undergradu¬ 
ate majors in Computer Science Engineering, 
Computer Science and Mathematics, and it has 
an active MS/PhD program with a heavy em¬ 
phasis on research. Its expanding departmental 
research facilities include an Encore Multimax 
processor, several VAX systems (8600,785, etc.), 
two Iris graphics workstations, a Ridge 32, 
numerous Sun, Microvax II and Apollo work sta¬ 
tions, and a number of special purpose systems 
all linked through Ethernet and serial com¬ 
munications networks. Other LAN systems are 
available, for instruction and research. General 
purpose campus facilities are available, and the 
supercomputer resources of the Lawrence Liver¬ 
more National Laboratories are also accessible. 
UC Davis is the third largest of the University of 
California campuses. It shares with the other 
campuses of the UC system a strong commit¬ 
ment to leadership in education and research. 
Davis is close to the major areas of computer 
science and electronics activity in northern 
California and thus is in a strategic position to 
play a key role in future developments of the 
discipline. 

The town of Davis has a population of approx¬ 
imately 50,000. Located eleven miles from Sacra¬ 
mento, it is situated within driving distance from 
the major cultural centers of the San Francisco 
area as well as the outstanding recreational 
facilities of the Sierra Nevada. The town has 
earned an international reputation for its pro¬ 
gressive energy-conservation policies. Because 
of its location, its climate, and its sophisticated 
small town character, Davis is considered by 
many to be an ideal living environment. 
Interested applicants should send a curriculum 
vitae with the names of at least three profes¬ 
sional references to Richard F. Walters, Chair, 
Division of Computer Science, or to S. Louis 
Hakimi, Chair, Department of Electrical Engi¬ 
neering and Computer Science, University of 
California, Davis, CA 95616. 

The University of California is an equal oppor¬ 
tunity/affirmative action employer. 


GEORGIA INSTITUTE OF TECHNOLOGY 
Director 

School of Information and Computer Science 

The Georgia Institute of Technology has re¬ 
opened its search for the position of Director of 
the School of Information and Computer Sci¬ 
ence. This position carries with it an appoint¬ 
ment as Full Professor. School directors at 
Georgia Tech exercise considerable leadership 
in the administration of their departments. 
Qualified persons with outstanding records of 
academic achievement are encouraged to apply. 
Applications will be accepted until 15 March 
1988. 


Computer Science at Georgia Tech 
The School of Information and Computer Sci¬ 
ence is one of the largest on the Georgia Tech 
campus. In the last fiscal year, the School 
graduated 106 students with Bachelor of Sci¬ 
ence degrees in its CSAB accredited program, 75 
with Master's degrees, and 7 with Ph.D.’s. 

The School’s researchers are active in many of 
the areas of contemporary computer science, 
with major research thrusts in artificial in¬ 
telligence, distributed computing and computer 
networks, and software engineering. The School 
maintains well-equipped research laboratories. 
Moreover, the School has recently been awarded 
a Coordinated Experimental Research grant 
from the National Science Foundation that will 
support the development of a testbed for distri¬ 
buted applications. The programs of the School 
are closely allied with a number of campus 
research efforts, notably those sponsored 
through the Microelectronics Research Center 
and the Cognitive Science Initiative. 

Ground has recently been broken fora new build¬ 
ing that will provide excellent research and 
teaching facilities for the School and for the 
Computer Engineering Program of the School of 
Electrical Engineering. 


About the University 

Georgia Tech is a technological university of ap¬ 
proximately 11,000 graduate and undergraduate 
students located on a traditional campus near 
downtown Atlanta. As a result of its selective ad¬ 
missions, Tech students are of exceptional 
quality. For example, Georgia Tech has the high¬ 
est percentage of National Merit Scholars of any 
publicly supported university in the nation. The 
student body has broad national representation. 
The programs in graduate education and re¬ 
search at Georgia Tech have experienced sub¬ 
stantial growth, particularly in the last two 
decades. The School of Information and Com¬ 
puter Science is expected to play a leadership 
role in the Institute’s drive to move into the first 
rank of research universities. Georgia Tech now 
ranks third nationally in sponsored expenditures 
for engineering research and development. In 
partnership, Atlanta and Georgia Tech are 
emerging as important magnets for high- 
technology industries. 

Nominations and applications should be sent to: 
Richard E. Cullingford, Chairman, ICS Director 
Search Committee, School of Information and 
Computer Science, Georgia Institute of Technol¬ 
ogy, Atlanta, Georgia 30332-0280. 

Georgia Tech is a unit of the University System 
of Georgia, and is an Equal Opportunity/Affir¬ 
mative Action Employer. 
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UNIVERSITY OF UTAH 
COMPUTER SCIENCE FACULTY POSITIONS 

The Department of Computer Science at the 
University of Utah solicits applications at all pro¬ 
fessorial ranks. A candidate for Assistant Pro¬ 
fessor must earn the Ph.D. in Computer Science 
or related field prior to September. A candidate 
for Associate Professor must have, in addition, 
at least three years of teaching or research ex¬ 
perience in Computer Science. A candidate for 
the rank of Professor must have a well-established 
research record in Computer Science. 

The Department currently has 16 tenure-track 
faculty members, 2 teaching faculty, as well as 
an additional eleven serving in research and ad¬ 
junct capacities. The student population in¬ 
cludes approximately 200 undergraduate majors, 
50 Master’s degree students, and 35 Ph.D. 
students. 

Substantially funded faculty research projects 
include: asynchronous computation, computer- 
aided geometric design, computer-aided instruc¬ 
tion, computer graphics, computer system architec¬ 
ture, computer vision, models of computation, 
program verification, programming languages, 
robotics, sensory information processing, soft¬ 
ware for small computer systems, symbolic and 
algebraic computation, theory of computation, 
and very large scale integrated circuit design. 
Funding sources include major support from the 
NSF/CER program and from DARPA. Other 
governmental agencies and private industry also 
provide significant support. 

Over the past few years, the department has 
created an outstanding research environment. 
The department maintains a professionally staffed 
research computing facility which includes a 
VAX 8600, five other VAX mainframes and a 
Gould 9080. An 18-node BBN Butterfly parallel 
computer system and over 70 Hewlett-Packard, 
Apollo and Sun workstations are installed. The 
facility is connected to most major geographic 
networks (Arpanet, CSNET, USENET and Tele¬ 
net). A computer graphics laboratory with equip¬ 
ment representative of the most advanced de¬ 
vices available in the industry is also available. 
Other specialized laboratories include facilities 
for image processing and understanding, robo¬ 
tics, parallel processing, lisp programming, com¬ 
puter aided instruction and VLSI research. 
Starting date for appointment is July 1988. Direct 
vita, along with the names of three or more refer¬ 
ences, by Feb. 1,1988 or until positions are filled 

Recruiting Committee Chairman 

Department of Computer Science 
University of Utah 
Salt Lake City, Utah 84112 
The University of Utah is an Affirmative Action/ 
Equal Opportunity Employer and especially en¬ 
courages application from women and members 
of minority groups. 


PRINCETON UNIVERSITY 
Research Associate and Post-DOC 

One or more research positions available im¬ 
mediately under several sponsored projects. The 
projects involve faculty, researchers and 
students, and cover the areas of databases, 
distributed systems, VLSI design, artificial in¬ 
telligence, and computer architecture. Respon¬ 
sibilities include the design and implementation 
of software systems as well as their experimen¬ 
tal evaluation. Ph.D with experience in at least 
one of the above areas Is required. Salary open. 
Send resume to: 

Hector Garcia-Molina 
Department of Computer Science 
Princeton University 
Princeton, N.J. 08544 

An affirmative action/equal opportunity employer. 


THE OHIO STATE UNIVERSITY 
Department of Computer and 
Information Science 

Applications are invited for faculty positions at 
all levels. A Ph.D. in computer science or a close¬ 
ly related field is required. Of special interest are 
candidates in the areas of artificial intelligence, 
computer graphics, databases, numerical analy¬ 
sis, programming languages, operating systems, 
parallel and distributed computing, software 
engineering, and VLSI design. Special research 
support packages are available for highly quali¬ 
fied candidates. 

Computing facilities within the Department in¬ 
clude a DEC-2060, three Pyramids, 20 Sun-3 
workstations, 10 IBM RTs, 15 Xerox LISP 
machines, an Intel iPSC/5 Hypercube, an Encore 
Multimax, a BBN Butterfly, numerous other 
systems for graphics, robotics, etc., and over 300 
Macintoshes. Macs are used in introductory 
computing courses. An additional 200 Sun-3 
workstations and 6 Hewlett Packard color 
graphics workstations will be installed this year 
for other instructional use. The OSU Computing 
Center facilities include a Cray XMP, IBM 
3081-D, and several IBM 4341s. All systems are 
attached to a campus-wide fiber optic network 
(Pronet 80) using TCP/IP protocols. Access is 
available to the national networks (ARPANET, 
CSNET, BITNET, USENET). 

To apply, please send application and resume to 
Prof. Ming T. (Mike) Liu, Chairman of Faculty 
Search Committee, Department of Computer 
and Information Science, The Ohio State Univer¬ 
sity, 2036 Neil Avenue, Columbus, Ohio 43210- 
1277 (CSNET/ARPANET Address: Liu@Ohio- 
State.) In order to expedite consideration, please 
ask three references to send their confidential 
letters directly to Prof. Liu. The Ohio State 
University is an equal opportunity/affirmative ac¬ 
tion employer. 


UNIVERSITY OF FLORIDA 
Computer & Information Sciences Department 

Applications are invited for visiting and tenure- 
track positions at the Assistant and Associate 
Professor levels. A Ph.D. in computer science or 
a related field is required. Preferred areas in¬ 
clude database management systems, software 
engineering, computer vision and artificial 
intelligence. Positions are available for Spring 
1988 as well as the 1988-89 academic year. 

The University of Florida, with over 35,000 
students, is the leading graduate education and 
research institution in the State. Our rapidly ex¬ 
panding department now numbers 19 doctorate 
faculty and offers programs leading to the BS, 
MS, and Ph.D. Department facilities include a 
Gould Powernode 9080 (4.3C BSD Unix), VAX 
11/750's (4.3 BSD Unix and VMS) supporting 
CSNET, 2 SUN Data Servers and workstations, 
IBM Series/1, and numerous (50 + ) smaller 
machines. Local area networks provide terminal 
access and inter-processor communication 
within the department and throughout the Col¬ 
lege of Engineering. Access to university main¬ 
frames (VAXs and IBM 3090, 3081, 4341) is also 
available. 

This search will be conducted in compliance 
with Florida’s “government in the Sunshine 
law”. Qualified applicants should send their 
resumes and the names of 3 references to: Dr. 
Gerhard X. Ritter, Computer and Information 
Sciences Department, 301 CSE, University of 
Florida, Gainesville 32611. 904/335-8000. 

Closing date: December 11, 1987 or until posi¬ 
tions are filled: An Equal Opportunity/Affirmative 
Action Employer. 


CHAIRPERSON 

DEPARTMENT OF COMPUTER SCIENCE 
AND ENGINEERING 

Oakland University, Rochester, Michigan 

The School of Engineering and Computer 
Science at Oakland University invites applica¬ 
tions for the position of Chairperson, Depart¬ 
ment of Computer Science and Engineering. 
Oakland University is a state-supported institu¬ 
tion of 12,000 students, located on a 1,400 acre 
campus in rural surroundings near Rochester, 
Michigan. This progressive community is ac¬ 
claimed for its cultural climate and quality of life. 
The School contains two other departments: 
Mechanical Engineering and Electrical and 
Systems Engineering. The Computer Science 
and Engineering Department has 14 full-time 
faculty members, 585 undergraduate and 115 
graduate students. The department offers bac¬ 
calaureate programs in both computer science 
and computer engineering as well as a masters 
program in computer science and engineering. 
An interdisciplinary Ph.D. program in systems 
engineering is also offered. Active areas of 
research within the department include software 
engineering, artificial intelligence, computer ar¬ 
chitecture, and real-time computing. Up-to-date 
laboratories support teaching and research ac¬ 
tivities. Computer facilities include a local area 
network, a Honeywell DPS-2 Multics mainframe 
computer with access to the statewide MERIT 
network, a VAX 780 and PRIME 9750 CAD facili¬ 
ty, and numerous microcomputers. The well- 
equipped and well-funded Center for Robotics 
and Advanced Automation promotes interdisci¬ 
plinary research excellence among the faculty. 
Located adjacent to the university, the new 
Oakland Technology Park provides a focus for 
collaborative research between the faculty and 
the large industrial community of southeast 
Michigan. 

Candidates must have an earned doctorate in 
engineering, computer science or a related field, 
a minimum of 5 years experience in engineering 
or computer science education, and be a citizen 
or permanent resident of the U.S. Additional 
qualifications include a demonstrated commit¬ 
ment to excellence in teaching, a record of 
distinguished scholarship, and proven ability to 
attract external funding and provide effective 
leadership for the department. Applicants 
should send a letter, resume and the names of at 
least three references to 
Dr. Robert M. Desmond, Dean 
School of Engineering and Computer Science 
Oakland University 
Rochester, Michigan 48063 
To ensure full consideration applications should 
be received by December 15,1987. Further appli¬ 
cations will be accepted until the position is 
filled. Oakland University is an equal opportunity 
affirmative action employer. 


THE UNIVERSITY OF TEXAS AT ARLINGTON 

The Department of Computer Science Engineer¬ 
ing (CSE) at The University of Texas at Arlington 
(UTA) invites your application for tenure-track or 
visiting faculty positions in all areas of computer 
science and computer engineering. Rank is 
open. An earned doctorate or equivalent and 
commitment to teaching and scholarly research 
is required. Openings are expected for January 
and September 1988. Interested persons should 
send a resume to Bill D. Carroll, Professor and 
Chairman, Computer Science Engineering De¬ 
partment, P.O. Box 19015, The University of 
Texas at Arlington, Arlington, TX 76019. Phone 
817-273-3785. 

The University of Texas at Arlington is an Equal 
Opportunity Affirmative Action Employer. 
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GEORGIA INSTITUTE OF TECHNOLOGY 
School of Information and Computer Science 

The School of Information and Computer 
Science invites applications for faculty posi¬ 
tions at all levels. Applicants should have a com¬ 
mitment to teaching and a record of outstanding 
research accomplishments. Applicants who ex¬ 
pect to receive a Ph.D. degree by Fall 1988 and 
who show high potential for research as well as a 
commitment to teaching are also invited. 

The School seeks applicants to strengthen its 
capabilities in all areas of current research ac¬ 
tivity, especially artificial intelligence, software 
engineering, distributed computer systems, and 
also in computer graphics, programming lan¬ 
guages, theoretical computer science, human 
factors, VLSI systems, data communications 
and computer networks, database systems, and 
computer architecture. Very competitive sala¬ 
ries are offered. 

The School has 27 faculty members and antici¬ 
pates further faculty growth. Its educational 
activities include an undergraduate program ac¬ 
credited by the Computing Sciences Accredita¬ 
tion Board, Inc., a Masters program with 150 
students and a Ph.D. program with over 70 
students. Well equipped laboratories support 
research and education. For instance, a recently 
established programming laboratory features a 
network of twenty-four Unix-based workstations. 
High-speed local area networks interconnect all 
major campus laboratories and provide access 
to national newtworks. 

The School has been named a 1987 recipient of a 
five year Coordinated Experimental Research 
grant from the National Science Foundation. 
This grant will fund acquisition of hardware and 
development of software to support experimen¬ 
tal work in parallel and distributed computing. 
Georgia Tech is located in Atlanta, which ex¬ 
periences a mild sunbelt climate. It is the center 
of commerce in the Southeast, offering a diverse 
economy and good employment opportunities in 
all professional areas. Atlanta offers good 
cultural and recreational opportunities, extreme¬ 
ly attractive residential neighborhoods, and af¬ 
fordable housing. 

Candidates should send complete resumes and 
names of at least three references to: Professor 
Richard J. LeBlanc; Chairman, Faculty Search 
Committee; School of Information and Com¬ 
puter Science; Georgia Institute of Technology; 
Atlanta, Georgia 30332. 

Georgia Tech is an equal opportunity employer. 


UNIVERSITY OF WISCONSIN-MADISON 

Faculty Positions—The Department of Elec¬ 
trical and Computer Engineering invites applica¬ 
tions for tenure and tenure-track positions. A 
Ph.D. degree is required, and successful can¬ 
didates are expected to participate in both 
teaching and research activities. Applicants in 
all areas of computer engineering are invited to 
apply, but the following areas are of special in¬ 
terest: computer architecture, computer net¬ 
works, VLSI and computer-aided design, micro- 
pocessor and minicomputer applications, real¬ 
time control and instrumentation applications, 
and engineering applications of artificial in¬ 
telligence. Rank and salary will be commensu¬ 
rate with qualifications and experience. Send 
resume and names of three references to J. Leon 
Shohet, Chairman, Department of Electrical and 
Computer Engineering, University of Wisconsin 
—Madison, 1415 Johnson Drive, Madison, Wl 
53706, an equal opportunity/affirmative action 
employer. 


STATE UNIVERSITY OF NEW YORK 
AT BUFFALO 

The Department of Computer Science is seeking 
faculty at all levels, Assistant, Associate and full 
Professor, to begin Fall, 1988. Applicants at the 
junior level must have a Ph.D. in Computer Sci¬ 
ence, or a related field, and superior research 
ability. Applicants at the senior level must have a 
proven research and funding record. 

The University at Buffalo is the largest public 
university in New York and New England, with 
approximately 26,000 students enrolled in 93 
undergraduate, 101 master’s and 94 doctoral pro¬ 
grams, including law, medical, and business 
schools. 

Present research areas include artificial in¬ 
telligence, computer vision, numerical analysis, 
parallel algorithms, theory of computation, VLSI, 
etc., with an annual research expenditure of $1 
million. The Department offers BA, BS, MS, and 
PhD degrees, with controlled undergraduate en¬ 
rollment. Departmental computing facilities in¬ 
clude a VAX 11/785, two VAX 11/750S, twelve 
SUNs, seven lisp machines and several image 
processing/graphics systems. The current de¬ 
partment consists of 14 tenure track faculty, 3 
lecturers, 3 full-time technical staff and over 60 
supported graduate students. The Department is 
expanding, with additional faculty lines commit¬ 
ted annually. Salaries are extremely competitive. 
Resumes and names of four references should 
be directed to: Prof. Sargur N. Srihari, Acting 
Chairman, Department of Computer Science, 
226 Bell Hall, SUNYat Buffalo, Buffalo, NY 14260 
(CSnet: srihari@buffalo). For full consideration, 
applications should be received by February 1, 
1988. SUNY is an affirmative action/equal oppor¬ 
tunity employer. 


UNIVERSITY OF ILLINOIS 
AT URBANA-CHAMPAIGN 

The Center for Supercomputing Research and 
Development (CSRD) at the University of Illinois 
at Urbana-Champaign has over $5 million per 
year support. CSRD is constructing the Cedar 
parallel processing supercomputer. 

CSRD is seeking an Associate Director for its 
Hardware and Architecture group. The position 
will be occupied by a faculty member who is 
tenured or on tenure-track in ECE or CS in con¬ 
junction with the full-time regular position of 
Associate Director in CSRD. The Associate 
Director will manage technology selection, 
designing, documenting, implementing, testing, 
maintaining, and updating computer hardware 
subsystems; will direct research in parallel com¬ 
puting, architecture and hardware; and will play a 
key role in specifying future Cedar systems. 
Ph.D. in ECE or CS required with 10 years ex¬ 
perience preferred. Experience should include 
but not necessarily be limited to state-of-the-art 
computer system design and project manage¬ 
ment. In rare instances, equivalent qualifications 
will be acceptable in lieu of those stated above. 
Please send resume including educational back¬ 
ground, recent professional experience, and 
salary requirement to: 

Judy Reinhart 
CSRD 

104 S. Wright St., 305 Talbot Lab 
Urbana, IL 61801 217/244-0056 

Salary commensurate with experience. 

In order to insure full consideration, all applica¬ 
tions should be submitted by November 30,1987. 
Interviews may take place before the closing date 
but no final decisions will be made until after the 
closing date. The starting date is flexible. 

The University of Illinois is an Affirmative Ac-. 
tion/Equal Opportunity Employer. 


PORTLAND STATE UNIVERSITY 
Department Head of Electrical Engineering 

Portland State University seeks an outstanding 
individual with an excellent understanding of the 
broad spectrum of electrical and computer engi¬ 
neering, who can promote quality teaching, ac¬ 
tive research, and interaction with industry. An 
earned Ph.D. in electrical engineering or a close¬ 
ly related field is required. Candidates should 
have nationally recognized achievement in re¬ 
search and educational activities and the ability 
to work effectively with students, faculty, and ad¬ 
ministration. Salary and rank are negotiable and 
commensurate with experience and qualifications. 
Portland State University, one of the three major 
universities in the Oregon State System of 
Higher Education, is located in Portland, Oregon 
near the confluence of the Willamette and Col¬ 
umbia rivers. Portland is a beautiful city that of¬ 
fers a diversity of recreation within easy driving 
distance—skiing and mountain climbing, the 
scenic Oregon coast, unmatched State camp¬ 
grounds, to name a few. 

Portland State University enrolls approximately 
15,000 students in a variety of comprehensive 
academic programs at both the undergraduate 
and graduate levels. The Department of Elec¬ 
trical Engineering offers B.S., M.S., and Ph.D. 
degrees in electrical and computer engineering. 
The Department has 12 full-time faculty and over 
200 students admitted to its upper division and 
graduate programs. Additional faculty will be 
recruited in the next two years, as the University 
continues to place special emphasis on the ex¬ 
pansion of its electrical and computer engineer¬ 
ing programs. 

The University is entering a new era of dynamic 
growth and development. During the past five 
years, the electronics and computer industry, 
the State of Oregon, and the City of Portland 
have launched major initiatives to expand elec¬ 
trical and computer engineering education and 
research. Portland has a rapidly growing elec¬ 
tronics and computer industry in its “silicon 
forest," including Tektronix, Intel, Floating Point 
Systems, Electro Scientific Industries, Hewlett- 
Packard, Sequent Computer Systems, Metheus, 
Mentor Graphics, etc., that permits close indus¬ 
try-university interaction. 

The position is available on or before July 1, 
1988. Nominations and applications will be ac¬ 
cepted until January 4, 1988, or until suitable 
candidates are identified. Forward nominations 
or applications, including resume and the names 
of three references, to Dr. Richard Morris, Chair¬ 
man, Electrical Engineering Department Head 
Search Committee, c/o Dean’s Office (EAS), 
School of Engineering and Applied Science, 
Portland State University, Portland, OR 97207. 
Portland State University is an Equal Opportuni¬ 
ty Affirmative Action employer. Minorities, 
women, and members of other protected groups 
are encouraged to apply. 


CALIFORNIA STATE 
POLYTECHNIC UNIVERSITY, POMONA 
Computer Science Department 

Computer Science: One or more tenure-track 
faculty positions beginning Sept. 1988. Assist, or 
Assoc. Prof., specialty open, academic year. 
Ph.D. strongly preferred (required for tenure or 
promotion). M.S. in C.S. plus enrollment in Ph.D. 
program with teaching experience is the min. 
qualification. Send resume, 3 reference letters, 
application form, by Feb. 15, 1988. Search 
Comm., Comp. Sci. Dept., Calif. State Poly Univ., 
Pomona, CA 91768. Only persons authorized to 
work in the U.S. will be hired. AA/EEO 
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UNIVERSITY OF CALIFORNIA, 

SANTA BARBARA 

The University of California at Santa Barbara in¬ 
vites applications for at least four tenure track 
positions in the Department of Computer Sci¬ 
ence, effective 1988-89 academic year. These 
positions are available at all professorial levels, 
although the Department has a strong interest in 
appointments at senior levels. The Department 
of Computer Science is in a rapidly expanding 
College of Engineering, which has achieved 
great prominence in several areas of research. 
UCSB and the College of Engineering are highly 
committed to augmenting Computer Science in 
order to build a Department of great excellence 
and having national visibility. The Department is 
currently undergoing a major expansion, both in 
terms of faculty and facilities. 

The positions currently available in Computer 
Science are in areas of research in which the 
Department intends to achieve its greatest 
strengths, namely Software Systems, Parallel 
and Distributed Computing, Machine Intelli¬ 
gence (particularly Computer Vision), and Scien¬ 
tific Computing. Senior appointments in these 
areas will provide opportunities for successful 
candidates to guide the growth and development 
of the Department. Resources will be available 
for state-of-the-art laboratories for research and 
instruction. Strong research support will be 
made available and tailored to the needs of suc¬ 
cessful applicants in these areas. Interactions 
with various research groups on campus, includ¬ 
ing the Center for Robotic Systems in Micro¬ 
electronics, The Center for Computational Sci¬ 
ences and Engineering, The Institute for Theo¬ 
retical Physics, and The Cognitive Science Pro¬ 
gram, will be strongly encouraged and supported. 
Applicants must possess a doctoral degree, and 
senior applicants must have an extremely strong 
record of research accomplishments. Teaching 
experience is desirable. Deadline for receipt of 
applications is January 31, 1988. Send resume 
and names of referees to: 

Chairman, Planning and Recruitment 
Committee 

Department of Computer Science 
University of California 
Santa Barbara, CA 93106 
Proof of U.S. citizenship or eligibility for U.S. 
employment will be required prior to employ¬ 
ment (Immigration Reform and Control Act of 
1986). The University of California is an Equal Op¬ 
portunity/Affirmative Action Employer. 


UNIVERSITY OF NEW HAMPSHIRE 
Assistant/Associate Professor 
Computer Science 

Two tenure track positions are available for 
January or September 1988 at the assistant or 
associate professor level. A PhD in Computer 
Science or closely related area is required. Ap¬ 
plicants are especially encouraged to apply who 
have research interests in parallel computing, ar¬ 
tificial Intelligence, data base systems or com¬ 
puter graphics. 

Department resources include an Ncube parallel 
computer, an IRIS graphics workstation, a VAX 
780 and a network of SUN-3 and MicroVAX-ll 
workstations. 

Submit resume and names of three references 
before December 1, 1987 to: Robert D. Russell, 
Chair, Department of Computer Science, Kings¬ 
bury Hall, University of New Hampshire, Dur¬ 
ham, NH 03824. 

UNH is an AA/EEO employer. 


SOUTHERN ILLINOIS UNIVERSITY 
AT CARBONDALE 

Applications are invited for three (3) tenure track 
faculty openings in a growing dynamic Com¬ 
puter Science Department. Candidates in all 
fields of computer science or computer 
engineering will be considered, with the depart¬ 
ment seeking to strengthen the areas of operat¬ 
ing systems, artificial intelligence, software 
engineering, and database systems. Applicants 
should demonstrate promise of ongoing and 
future research, a commitment to teaching, and 
willingness to participate fully In the depart¬ 
ment’s graduate and undergraduate programs. 
Departmental facilities include a network of per¬ 
sonal computers, a VAX work station, and a 
shared memory parallel machine, the Sequent 
Balance 8000. In addition, a host of IBM main¬ 
frame computers are available for research and 
teaching purposes. Two positions are at the 
assistant/associate level beginning August 16, 
1988. A third position is also available at the 
assistant professor level beginning January 1 or 
August 16, 1988. Applications will be accepted 
until March 15, 1988 or until the positions are 
filled. To be considered for the January 1 ap¬ 
pointment applications must be received by 
November 15,1987. A Ph.D. will be required as of 
date of employment. Resumes should be sent to: 
Faculty Recruitment Committee, Department of 
Computer Science, Southern Illinois University, 
Carbondale, IL 62901. SIUC is an Equal Oppor¬ 
tunity, Affirmative Action Employer. 


CALIFORNIA STATE UNIVERSITY 
San Bernardino 

POSITION FOR ASSISTANT PROFESSOR 
(tenure track) of COMPUTER SCIENCE. Salary 
range $31,489-$37,871 dependent on qualifica¬ 
tions and experience. 

Duties include teaching, advising, curriculum 
development, program evaluation, and com¬ 
munity interaction. Teaching load equated to 12 
hrs/wk of lecture and lab. Ph.D. in CSci is prefer¬ 
red, but an MS in CSci with Ph.D. in related field 
will be considered. Facilities include CDC Cyber 
720 and 730-760, Prime 9750, DEC PDP 11 com¬ 
puters, many PCs, microprocessors and terminals. 
The University is located in one of the fastest 
growing service areas in the USA with a current 
student population of about 8000 and more than 
300 computer science majors. The area is noted 
for its warm climate and is within one hour of 
beaches, mountain resorts and metropolitan Los 
Angeles without their high living costs. Ap¬ 
plicants should submit letter of application, 
vitae, 3 current letters of recommendation and 
official transcripts. Selection will be completed 
no sooner than 1/16/88. Closing Date: 3/1/88. 
Send materials to: Dr. Richard J. Botting, Chair, 
Department of Computer Science, California 
State University, 5500 University Parkway, San 
Bernardino, CA 92407, PAAAAAR@CALSTATE. 
BITNET 

An Equal Opportunity/Affirmative Action, Sec¬ 
tion 504, Title IX Employer. 


COMPUTER SCIENTIST 

Unique opportunity with a R&D startup firm, 
ideal city for a motivated, goal oriented person to 
develop compilers. Qualified applicants will 
have B.S. in Computer Science with experience 
in compiler development, database implementa¬ 
tion, C and Ada programming. Knowledge of 
parallel, microprogrammable architectures a 
plus. Send resume and salary history to: SPACE 
TECH CORP., 125 Crestridge Drive, Ft. Collins, 
CO 80525. EOE/AA 


UNIVERSITY OF ILLINOIS 
AT URBANA-CHAMPAIGN 

The Center for Supercomputing Research and 
Development (CSRD) at the University of Illinois 
at Urbana-Champaign has over $5 million per 
year support. CSRD is constructing the Cedar 
parallel processing supercomputer. 

CSRD is seeking an Associate Director for its 
Hardware and Architecture group. The position 
will be occupied by a faculty member who is 
tenured or on tenure-track in ECE or CS in con¬ 
junction with the full-time regular position of 
Associate Director in CSRD. The Associate 
Director will manage technology selection, de¬ 
signing, documenting, implementing, testing, 
maintaining, and updating computer hardware 
subsystems; will direct research in parallel com¬ 
puting, architecture and hardware; and will play a 
key role in specifying future Cedar systems. 
Ph.D. in ECE or CS required with 10 years ex¬ 
perience preferred. Experience should include 
but not necessarily be limited to state-of-the-art 
computer system design and project manage¬ 
ment. In rare instances, equivalent qualifications 
will be acceptable in lieu of those stated above. 

Please send resume including educational back¬ 
ground, recent professional experience, and 
salary requirement to: 

Judy Reinhart 
CSRD 

104 S. Wright St., 305 Talbot Lab 
Urbana, IL 61801 217/244-0056 

Salary commensurate with experience. 

In order to insure full consideration, all applica¬ 
tions should be submitted by November 30,1987. 
Interviews may take place before the closing date 
but no final decisions will be made until after the 
closing date. The starting date is flexible. 

The University of Illinois is an Affirmative Ac¬ 
tion/Equal Opportunity Employer. 


GEORGE WASHINGTON UNIVERSITY 
TENURE-TRACK 
FACULTY POSITIONS 

The Department of Electrical Engineering and 
Computer Science invites applications for 
tenure-track faculty positions in Electrical 
Engineering and Computer Science. Candidates 
should have an earned doctorate and research 
experience, with an interest in both teaching and 
research. Ability to attract research grants and 
contracts for support of faculty and student 
assistants is valued. The George Washington 
University is located in the center of Washing¬ 
ton, DC. This metropolitan area sustains the sec¬ 
ond largest concentration of research and devel¬ 
opment activity in the United States which 
creates a continuing demand for rigorously train¬ 
ed engineers as well as broad research oppor¬ 
tunities. Our department is the largest depart¬ 
ment in the School of Engineering and Applied 
Sciences with 37 full-time faculty, and a large 
graduate and undergraduate student body. The 
department has an annual research budget of 
close to $1 million. Send Curriculum Vita, list of 
publications and references, to: 

Professor Roger H. Lang, Chairman 
Department of Electrical Engineering and 
Computer Science 

School of Engineering & Applied Sciences 
THE GEORGE WASHINGTON UNIVERSITY 
Washington, DC 20052 

The George Washington University is an affir¬ 
mative action/equal opportunity employer. 
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THE UNIVERSITY OF TENNESSEE 
Department of Computer Science 
Knoxville, Tennessee 37996-1301 

The Department of Computer Science invites ap¬ 
plications for tenure-track and visiting positions 
at all ranks beginning Winter of 1988. A doctoral 
degree in computer science or a related area, 
and a strong interest in research in the areas of 
computer networks, computer graphics, and 
operating systems are required. Those with ex¬ 
perience directing doctoral students are espe¬ 
cially encouraged to apply. 

The department operates a research laboratory 
which contains two DEC VAX-8200’s (one VMS, 
one UNIX) and a variety of microcomputers. Each 
faculty member has a personal workstation. 
Specialized laboratories support research in 
areas of special emphasis. The University of Ten¬ 
nessee Computing Center operates an IBM 3081, 
an IBM 4381, and a cluster of VAX 8600’s. Faculty 
members collaborate with scientists at the Oak 
Ridge National Laboratory and frequently have 
access to their facilities, including a Cray X-MP 
and hypercube computers, under the terms of 
the collaboration. Faculty workstations are net¬ 
worked with the departmental laboratories, the 
University Computing Center, and facilities at 
the Oak Ridge National Laboratory. 

You can respond on CSNET with csnet:straight 
@utenn and on BITNET with bitnet:straight@ 
utkcsl. The mailing address is Computer Sci¬ 
ence Department, 107 Ayres Hall, The University 
of Tennessee, Knoxville TN 37996-1301. 

The University of Tennessee is an EEO/TITLE 
IX/SECTION 504 employer. 


CLARKSON UNIVERSITY 
Department of Electrical and 
Computer Engineering 

Applications are invited for the position of 
Chairperson, which will become available on July 
1,1988. The requirements include: an earned PhD 
degree in electrical engineering or a closely 
related discipline; distinguished accomplish¬ 
ments in both engineering education and re¬ 
search; and an ability to provide dynamic leader¬ 
ship. The position requires academic administra¬ 
tion of the department, while continuing to main¬ 
tain interaction with the students in the form of 
teaching and research. There are currently 25 full 
time faculty members, 800 undergraduates, and 
60 graduate students working toward MS and 
PhD degrees. The research areas are diverse and 
include communications, computer engineer¬ 
ing, control and robotics, electromagnetics, 
power engineering, and solid state. Annual 
grants and contracts total approximately $1M. 
The chairperson should provide the driving force 
in an ongoing effort to improve the strengths of 
the department, in terms of both quality funded 
reserach and excellence in teaching. Clarkson is 
a small independent college specializing in 
engineering, science, and management. The 
total student population is approximately 4000, 
of which 10% are studying at the graduate level. 
Clarkson is situtated in Northern New York, lying 
between the St. Lawrence River and the Adiron- 
dak mountains. Neighboring colleges include St. 
Lawrence University and Potsdam College. 
Please send a resume and 3 references, by 
February 29, 1988, to Dr. Paul B. McGrath, 
Department of Electrical and Computer 
Engineering, Clarkson University, Potsdam, NY 
13676. Clarkson is an Equal Opportunity/Affir¬ 
mative Action employer. MFVH 


UNIVERSITY OF ALASKA 

The Computer Science faculty invite applica¬ 
tions for anticipated tenure-track faculty posi¬ 
tions, to be filled January, 1988 and September, 
1988. Rank depends on qualifications. The 
University of Alaska-Fairbanks is the major 
research institution in the University of Alaska 
system and is the site of several world famous 
research institutes. The Department of Mathe¬ 
matical Sciences offes B.S. and M.S. degrees in 
Computer Science. The University facilities in¬ 
clude a research quality library and a statewide 
computer network of VAX 8800 and 8600 com¬ 
puters. In addition, the Department has a VAX 
11/750, PDP 11/23, several Masscomp color 
graphics work stations, and smaller computers. 
Applicants should have a Ph.D. in Computer 
Science or equivalent. Applicants with research 
interests in any field will be considered. Some 
preference will be given to applicants with exper¬ 
tise in database, architecture, and operating 
systems. Salary is competitive and fringe bene¬ 
fits are excellent. Resume and three letters of 
reference should be directed to Dr. Clifton Lan- 
do, Head, Department of Mathematical Sci¬ 
ences, University of Alaska, Fairbanks, AK 
99775-1110. Inquiries: (907) 474-7117 or FFBML® 
ALASKA.BITNET. Deadline for applications: 
Dec. 15, 1987 for January start, and March 1, 
1988 for September. UAF is an Equal Opportunity/ 
Affirmative Action employer and educational 
institution. 


UNIVERSITY OF MIAMI 

Department of Electrical and Computer Engi¬ 
neering has open faculty positions in microelec¬ 
tronics and computer engineering. Applicants 
should have demonstrated potential for excel¬ 
lence in research and teaching as well as doc¬ 
toral degree in a related area. Rank and salary 
commensurate with qualifications and academic 
or industrial experience. The department has a 
VAX-11/750, two MICRO VAX II, several AT&T 
3B2s and other microcomputers as well as ac¬ 
cess to Gould, Harris, IBM, and VAX 8650 
systems. Please forward resume and three refer¬ 
ences to: Joseph E. Urban, Chairman, Depart¬ 
ment of Electrical and Computer Engineering, 
University of Miami, P.O. Box 248294, Coral 
Gables, Florida 33124. An affirmative action/ 
equal opportunity employer. 


YORK UNIVERSITY 

Faculty of Science. Department of Computer 
Science. Tenure track positions at the Assistant, 
Associate, or Full Professor level. A PhD in Com- 
puter Science, Electrical Engineering or the 
equivalent is required. Preferred areas are: net¬ 
working and communications as well as com¬ 
puter architecture. 

Duties include research and teaching. The 
Department’s equipment includes a VAX8600 
(VMS) and SUN3/160, SUN3/280, and several 
SUN3/50’s, as well as microcomputer and 
graphics laboratories. Faculty and students also 
have access to IBM 4381 (VM/CMS) facilities. 
York University is located in Metropolitan Toronto 
and within easy reach of downtown Toronto 
which offers excellent cultural, recreational, and 
entertainment facilities. Send curriculum vitae 
and names of three references to Prof. E. Arjo- 
mandi, Chair, Department of Computer Science, 
Faculty of Science, York University, North York, 
Ontario, Canada M3J 1P3. York University is im¬ 
plementing a policy of employment equity. Quali¬ 
fied women and men are invited to apply. In ac¬ 
cordance with Canadian immigration require¬ 
ments, priority will be given to Canadian citizens 
and permanent residents of Canada. 


TEXAS A&M UNIVERSITY 
Department of Computer Science 

Applications are invited for faculty positions at 
the Assistant, Associate or Full Professor level. 
Candidates from all areas of computer science 
will be considered. Of particular interest are 
areas central to the design of fifth generation 
computer systems. In addition to regular faculty 
positions, an endowed chair in computer ar¬ 
chitecture is to be filled. 

The Department of Computer Science has 20 
full-time equivalent senior faculty members and 
additional teaching staff. There is a tradition of 
quality instruction at the B.S., M.S. and Ph.D. 
levels. The University has initiated a major com¬ 
mitment to develop excellence in Intelligent 
Systems, Artificial Intelligence, Software Tech¬ 
nology, Simulation and other areas of Computer 
Science. 

Computer Science at Texas A&M University is 
located in the College of Engineering. With near¬ 
ly 9,300 students, the College of Engineering is 
one of the nation’s largest. Computer Science is 
expanding to become one of the larger and more 
comprehensive departments in the country. 

We seek excellence in research. Texas A&M will 
provide superior instructional and research 
facilities for its Computer Science faculty. The 
University has the internal resources to achieve 
this goal. Applicants at the assistant professor 
level should show substantial promise for 
research and teaching. Applicants at the higher 
levels should show a strong record of research 
achievement. Ability in teaching graduates and 
under-graduates is also essential. Applicants 
should have a doctoral degree or its equivalent. 
Applicants should submit a resume and three 
references to Glen N. Williams, Head, Computer 
Science Department, Texas A&M University, Col¬ 
lege Station, TX 77843. 

Texas A&M University is an equal opportunity/af¬ 
firmative action employer. 


UNIVERSITY OF NEW HAMPSHIRE 
Chairperson of Computer Science 

The University of New Hampshire invites ap¬ 
plications and nominations for the position of 
Chairperson of the Computer Science Depart¬ 
ment. We are seeking an individual who can pro¬ 
vide innovative and dynamic leadership in the 
development of both educational and research 
programs. This person must have a Ph.D. and a 
distinguished record of research and scholar¬ 
ship in a specialized area of Computer Science. 
The department currently has eleven full-time 
faculty members. 35 graduate students and 180 
undergraduates enrolled in M.S. and B.S. degree 
programs. Plans are underway to institute a 
Ph.D. program. 

Department resources include an Ncube parallel 
computer, an IRIS graphics workstation, a VAX 
780 and a network of SUN-3 and Micro VAX-II 
workstations. The department has a commit¬ 
ment to excellence in both teaching and re¬ 
search and supports this commitment with a 
teaching load that makes both possible. 

UNH is located in the seacoast region of New 
Hampshire, 100 kilometers north of Boston. 
Nominations and applications, including cur¬ 
riculum vitae and the names of three references, 
will be accepted until January 1, 1988. Please 
respond to: Robert D. Russell, Chairman, Depart¬ 
ment of Computer Science, Kingsbury Hall, Uni¬ 
versity of New Hampshire, Durham, NH 03824, 
603-862-3778. 

UNH is an Equal Opportunity/Affirmative Action 
employer. 
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UNIVERSITY OF CALIFORNIA, SANTA CRUZ 
Computer Engineering 
Computer and Information Sciences 

The CE and CIS Boards of Studies invite applica¬ 
tions, as appropriate, for tenure track positions 
as Assistant, Associate or Full Professor, effec¬ 
tive July 1, 1988. UCSC is the University of 
California campus nearest to “Silicon Valley” 
where it is developing close research ties with 
local industry in the computer field. Faculty 
salaries are competitive, and opportunities for 
consulting are extensive. 

Computer Engineering has openings, tenured or 
untenured as appropriate, with emphasis given 
to faculty with research focus in software 
engineering; computer and systems architec¬ 
ture; communications; and parallel environ¬ 
ments (#63-867); or special purpose architecture 
as in signal and image processing and computer 
graphics (#31-856). A Ph.D. in Computer Engi¬ 
neering, Electrical Engineering, Computer Sci¬ 
ences or equivalent and a solid research record 
as evidenced by publication in technical journals 
is required. Applicants will be evaluated on their 
research record, teaching and professional ac¬ 
tivities and their demonstrated leadership in the 
field. Industrial experience will be favorably con¬ 
sidered. Candidates for tenured positions should 
apply before January 18,1988, while those apply¬ 
ing at the Assistant Professor level have until 
February 29,1988. 

Computer and Information Sciences wishes to 
hire at the assistant professor level, with priority 
given to candidates with strengths in the areas 
of software engineering, programming lan¬ 
guages and/or compiler construction (#77-867). A 
Ph.D. as above is required and applicants will be 
evaluated on their research record, teaching and 
professional activities. Apply before February 
29,1988. 

Send curriculum vitae with cover letter, teaching 
evaluations, copies of any recent publications, 
and letters of recommendation evaluating your 
scholarly contributions, teaching, and other pro¬ 
fessional accomplishments to: 

Chair, Computer Faculty Search Committee 
Applied Sciences Building, 

University of California 
Santa Cruz, California, 95064 
Please refer to a Provision # above when apply¬ 
ing. All candidates should indicate citizenship 
and, in case of non-US citizens, describe their 
visa status. The University of California is an 
EEO/AA/IRCA employer. 


CLEMSON UNIVERSITY 

ELECTRICAL and COMPUTER ENGINEERING 
at CLEMSON UNIVERSITY is seeking applicants 
for tenure-track positions in Computer Engineer¬ 
ing program offering BS, MS and PhD degrees. 
All areas of computer engineering are of interest, 
with special emphasis on distributed system 
software and hardware, computer networking 
and computer architecture. Tenure-Track Posi¬ 
tions in Electrical Engineering degree program 
also available, with areas of specialization in¬ 
cluding microelectronics, reliability, robotics, 
communications, signal processing, electro¬ 
magnetics and power. Visiting Positions may 
also be available. Applicants for Tenure Track 
positions must have a PhD and a strong interest 
in teaching and research. Research Associate 
positions (BS, MS) are also available. Send 
resumes to Dr. A. Wayne Bennett, E&CE Depart¬ 
ment, Clemson University, Clemson, S.C. 
29634-0915. Clemson is an Equal Opportunity/Af¬ 
firmative Action Employer. 


CLAREMONT McKENNA COLLEGE 
Endowed Position in Computer Science 
and Applied Mathematics 

Applications are invited for an endowed tenure- 
track position in Computer Science and Applied 
Mathematics with rank and salary dependent on 
qualifications. Starting date fall 1988. 

Claremont McKenna College is a liberal arts col¬ 
lege with 800 students. It is a member of the 
Claremont Colleges (along with Pomona, 
Scripps, Harvey Mudd, and Pitzer Colleges and 
Claremont Graduate School). The Claremont 
Colleges have a total of forty-three mathemati¬ 
cians and computer scientists, and are located 
in Claremont, Southern California. 
Qualifications for the position include a Ph.D. in 
a computer-related field such as Computer 
Science, Mathematics, Operations Research, or 
Information Science. If the degree is in a field 
otherthan Computer Science, substantial formal 
education in Computer Science is required. 
Applicants should have a strong commitment to 
undergraduate teaching, an established scholar¬ 
ly record, and practical experience with com¬ 
puter applications. The appointee will be ex¬ 
pected to teach some applied mathematics 
courses in addition to computer science courses 
and to participate in course and program 
development. 

The College is an equal opportunity/affirmative 
action employer. Applications will be reviewed 
as soon as received and a decision reached pre¬ 
ferably by January 1988. Please send resume 
and the names of four references to Professor 
John Ferling, Chairman, Computer Science 
Search Committee, c/o Dean of Faculty’s Office, 
Claremont McKenna College, Claremont, CA 
91711. 


UNIVERSITY OF CALIFORNIA BERKELEY 

THE UNIVERSITY OF CALIFORNIA AT 
BERKELEY invites applications for tenure-track 
positions in COMPUTER SCIENCE. Applica¬ 
tions for appointments at the ASSISTANT PRO¬ 
FESSOR level will be given highest preference, 
but other levels will be considered. 

The Computer Science Division of the Depart¬ 
ment of Electrical Engineering and Computer 
Sciences is strong and growing. We are in¬ 
terested in outstanding Computer Science can¬ 
didates in all areas. 

Research facilities include several mainframe 
computers (VAX 8600 and similar), numerous 
LISP machine (Symbolics, Tl, Xerox) worksta¬ 
tions, 80 general-purpose networked worksta¬ 
tions (SUN and similar), and access to an on-site 
IBM 3090 and Cray-XMP. Instructional hardware 
includes numerous SUN workstations, VAX 
systems, Macintoshes, PC’s and access to an 
IBM 3090. 

A doctoral degree in Computer Science or a 
closely related field is required. Applicants 
should be able to teach core undergraduate 
courses and graduate courses. The successful 
candidate must have demonstrated outstanding 
research accomplishments. Send resume, a 
select subset of your best papers, and the names 
of three references by December 31,1987, to the 
address below. 

Professor Richard Fateman 
Associate Chairman for Computer Science 
Department of Electrical Engineering and 
Computer Sciences 
University of California 
Berkeley, CA 94720. 

The University of California is an Equal Oppor¬ 
tunity, Affirmative Action Employer. 


MISSISSIPPI STATE UNIVERSITY 
Head, Department of Computer Science 

Mississippi State University invites applications 
and nominations for the position of Head of the 
Department of Computer Science. An individual 
with excellent leadership skills, with faculty ex¬ 
perience in a doctoral granting department, and 
with a successful record of research and teach¬ 
ing is desired. An earned doctorate in computer 
science or a related field is required. 

With a newly approved computer science doc¬ 
toral program, a computer science building 
renovation in progress, a recent $12 million grant 
for a research center for scientific computing, 
and the creation of the Center for Robotics, 
Automation and Artificial Intelligence, this posi¬ 
tion offers an excellent opportunity in leading 
the development and expansion of the research 
and graduate programs of the department. The 
department currently has approximately 400 
undergraduate students enrolled in a CSAB- 
accredited undergraduate program, about 200 
undergraduate students in a computer engineer¬ 
ing program that is jointly administered with 
Electrical Engineering, and 70 graduate stu¬ 
dents. The department is organized in the Col¬ 
lege of Arts and Sciences with fifteen full-time 
faculty. In addition, several faculty from 
Mathematics and Engineering have a joint ap¬ 
pointment with Computer Science. 

Mississippi State University is the state’s largest 
institution and leading research university. It is a 
comprehensive, land-grant institution with 
teaching, research and service programs span¬ 
ning a broad range of disciplines and profes¬ 
sions. It is located in Starkville, a college town 
with a population of 20,000, approximately 2-3 
hours driving time from Memphis, TN, Birming¬ 
ham, AL, and Jackson, MS. Starkville shares a 
regional airport with the nearby towns of Colum¬ 
bus and West Point. 

Screening of candidates will begin November 23, 
1987, and will continue until the position is filled. 
The expected appointment date is August 1, 
1988 or earlier if possible. Applications should 
be accompanied by the names of at least four 
references and should be sent to: Dr. T. T. Crow, 
Chair of Search Committee, College of Arts and 
Sciences; P.O. Drawer AS, Mississippi State, MS 
39762. 

Mississippi State University is an Equal Oppor¬ 
tunity/Affirmative Action Employer. 


UNIVERSITY OF MARYLAND 

Computer Vision/Human-Computer Interaction: 
Assistant, Associate and Full Research Scien¬ 
tists to direct advanced research programs in 
computer vision or human-computer interaction. 
One year renewable positions whose availability 
and continuation are dependent on contract/ 
grant funds. Depending on the area of research, 
Ph.D. in computer science, psychology, or closely 
related discipline required. For computer vision 
positions, experience in computer vision research 
required, specifically in areas such as three- 
dimensional and time-varying scene analysis, 
robot navigation, knowledge based vision sys¬ 
tems, and computer architectures for vision. For 
human-computer interaction positions, experi¬ 
ence is required in areas such as development of 
user interfaces and human factors testing. 
Salary up to $60,000 depending on level of posi¬ 
tion. Closing date for accepting applications is 
September 1, 1988. Indicate which position and 
for which area of research you are applying and 
submit signed and dated curriculum vitae plus 
three references to: Barbara Hope, Center for 
Automation Research, University of Maryland, 
College Park, MD 20742-3411. AA/EOE 
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Swiss Federal Institute of Technology (ETH) 
ZURICH, SWITZERLAND 

The Swiss Federal Institute of Technology (ETH 
Zurich) has two openings for Professors in Com¬ 
puter Science, Senior or Junior Faculty Posi¬ 
tions. The new faculty members are expected to 
pursue research in their fields of specialization 
in the Department of Computer Science. The fol¬ 
lowing fields of research are of particular interest 
—System software and operating systems 
—Digital circuits and computer hardware 
—Databases 
—Expert systems 
—Computer communication 
They are also expected to participate in the 
teaching of introductory courses for several 
departments of ETH and to offer courses at the 
graduate level. Junior faculty positions are in¬ 
itially for a term of 3 years renewable for an addi¬ 
tional 3 years. 

Candidates are invited to submit their applica¬ 
tion together with a curriculum vitae, a list of 
publications, references, and a description of 
their research activities and plans before February 
15, 1988, to the President of ETH, Prof. H. Buhl- 
mann, ETH-Zentrum, 8092 Zurich, Switzerland. 
For further information please contact Prof. P. 
LAuchli, Head of the Dept, of Computer Science, 
ETH-Zentrum, 8092 Zurich, Switzerland. 


THE UNIVERSITY OF TEXAS AT AUSTIN 

Electrical and Computer Engineering Depart¬ 
ment is accepting applications for tenure and 
tenure-track faculty positions. Qualifications 
must be commensurate with rank and include an 
outstanding academic record, significant 
achievement in original research, sincere in¬ 
terest in teaching, and a doctorate in electrical or 
computer engineering/science. Duties will in¬ 
clude teaching undergraduate and graduate 
courses. Interested applicants are invited to 
send resumes which detail their past profes¬ 
sional accomplishments, and which include the 
names and addresses of three references, to Dr. 
Edward J. Powers, Chairman, Department of 
Electrical and Computer Engineering, The Uni¬ 
versity of Texas at Austin, Austin, Texas 78712- 
1084, an Equal Opportunity/Affirmative Action 
Employer. 


WRIGHT STATE UNIVERSITY 
Chairperson, Computer Science and Engineering 

Wright State University seeks applications for 
Chairperson for the Department of Computer 
Science and Engineering. The Department has 
27 full time Faculty, and 150 Graduate students 
and is growing steadily in size, funding, publica¬ 
tions, and resources. It awards BS, MS, and 
PhDs in Computer Science and Computer Engi¬ 
neering. WSU is located in Dayton, half a mile 
from Wright Patterson Air Force Base and a few 
miles from NCR. The graduate program of the 
Department is located in the adjacent Miami 
Valley Research Park, where WSU is playing a 
leadership role. The Park includes federally, 
state, and industrially funded research organiza¬ 
tions such as the WSU affiliated Materials 
Center and Al Institute. The candidate will have 
earned a PhD in a related discipline, and have a 
record of funding, publication, and commitment 
to undergraduate and graduate teaching. Please 
send applications with the names of three refer¬ 
ences to the Chairperson Search Committee, 
Department of Computer Science and Engineer¬ 
ing, E and M130, Dayton, OH 45435. Closing date 
is 1 Feb. 1988 or until the position is filled. 
Wright State University is an equal opportunity/ 
affirmative action employer. 


UNIVERSITY OF CALIFORNIA, 

SANTA BARBARA 

University of California, Santa Barbara, Electrical 
and Computer Engineering. Applications are in¬ 
vited for tenure-track faculty positions, effective 
7/1/88. Three positions are open for candidates 
experienced in millimeter-waves and micro- 
waves; image processing; computer vision; or 
mutlivariable, robust, or fault-tolerant control 
system design. Two additional positions are an¬ 
ticipated for candidates with experience in com¬ 
puter engineering or optoelectronics. The posi¬ 
tions start at the rank of Assistant Professor, 
although higher level appointments are possible 
for individuals with outstanding records. Nor¬ 
mally, completion of a doctorate is required at 
the time of the appointment. Candidates should 
have an outstanding research potential or a 
distinguished research reputation, the ability to 
attract external research funding, and a strong 
commitment to teaching at the undergraduate 
and graduate levels. Applicants should send 
their resume and the names and addresses of at 
least four professional references, along with a 
brief statement of their research specialization 
to: Chairman, Faculty Search Committee, 
Department of Electrical and Computer Engi¬ 
neering, University of California, Santa Barbara, 
CA 93106, (805) 961-3821. Applications will be 
received until the positions are filled. Proof of 
U.S. citizenship or eligibility for U.S. employment 
will be required prior to employment (Immigra¬ 
tion Reform and Control Act of 1986). An Equal 
Opportunity/Affirmative Action employer. 


TECHNICAL UNIVERSITY OF NOVA SCOTIA 
Computer Science 

Applications are invited for tenure track faculty 
positions in the School of Computer Science of 
the Technical University of Nova Scotia. Duties 
will include teaching of senior undergraduate 
and graduate courses, and graduate student 
supervision. A Ph.D. is required, with evidence of 
excellent research accomplishments or poten¬ 
tial. Applications should be directed to the Direc¬ 
tor, School of Computer Science, Technical Uni¬ 
versity of Nova Scotia, P.O. Box 1000, Halifax, 
N.S. B3J 2X4. 


UNIVERSITY OF MARYLAND 
Institute for Advanced Computer Studies 

The University of Maryland Institute for Advanced 
Computer Studies (UMIACS) was established in 
1985 as an independent state-funded research 
unit. UMIACS, while residing on the College Park 
campus, is intended to serve the entire Universi¬ 
ty of Maryland system as a focal point for re¬ 
search activities in computing. 

UMIACS has 25 tenure track research faculty 
lines, in addition to a substantial operating 
budget to support the research activities of its 
faculty. Most faculty members in UMIACS will 
hold joint appointments with academic depart¬ 
ments on the campus; their teaching respon¬ 
sibilities would be reduced according to their 
percentage appointments in UMIACS. 

Several faculty positions have been reserved for 
permanent, full-time appointments in the In¬ 
stitute. These appointments are for senior level 
faculty and will include commitments from the 
Institute for research support (e.g. equipment, 
travel, graduate students, etc.) Applicants for 
these permanent positions should send a com¬ 
plete resume and names of four references to 
Prof. Larry S. Davis, Director, University of Mary¬ 
land Institute for Advanced Computer Studies, 
College Park, MD 20742. The University of Mary¬ 
land is an equal opportunity and affirmative ac¬ 
tion employer. Women and minorities are en¬ 
couraged to apply. 


UNIVERSITY OF WASHINGTON 
Computer Engineering 

Applications are invited for tenure-track faculty 
positions in all areas of computer engineering. 
Our particular interests include microproces¬ 
sors and digital systems, hardware and architec¬ 
ture, computer aided design and engineering, 
networks, VLSI design and test, applied artificial 
intelligence, computer graphics, and signal and 
image processing. The Computer Engineering 
Program is part of the Department of Electrical 
Engineering which has over 40 faculty members, 
and 500 undergraduate and 240 graduate stu¬ 
dents. Responsibilities include undergraduate 
and graduate teaching, and development of 
strong research programs. Senior faculty posi¬ 
tions are also available, with the possibility of an 
endowed professorship for candidates with ex¬ 
ceptional qualifications. At the assistant pro¬ 
fessor level, these positions may be eligible for 
career development awards which provide for 
summer research support and conference travel 
for up to three years. Positions are available ef¬ 
fective Autumn Quarter 1987 or until filled. Send 
resume with four references to Computer Engi¬ 
neering Faculty Search Committee, Department 
of Electrical Engineering FT-10, University of 
Washington, Seattle, WA 98195. The University 
of Washington is an EO/AAE. 


VANDERBILT UNIVERSITY 
Electrical Engineering 

Applications for faculty positions at all ranks in 
computer engineering are solicited from highly 
qualified individuals. Individuals will be selected 
primarily for their ability or potential to conduct 
research and to participate in a department com¬ 
mitted to an expansion of its graduate, research 
and instructional programs. The School of Engi¬ 
neering is the oldest and largest private engi¬ 
neering school in the South. Vanderbilt is lo¬ 
cated in Nashville, TN, one of the South's most 
rapidly expanding metropolitan areas. Highly 
qualified applicants should send their resumes 
and the names of three references to: EE Search 
Committee, Electrical Engineering, Vanderbilt 
University, Box 1824, Station B, Nashville, TN 
37235. Vanderbilt University is an Affirmative Ac¬ 
tion/Equal Opportunity Employer. 


UNIVERSITY OF MARYLAND 
CHAIRPERSON AND PROFESSOR 
COMPUTER SCIENCE DEPARTMENT 

The University of Maryland at College Park in¬ 
vites applications and nominations for the posi¬ 
tion of Chairperson and Professor of its Com¬ 
puter Science Department. Candidates for the 
position should have a well-established reputa¬ 
tion in research and teaching in computer sci¬ 
ence, and have demonstrated ability to lead a 
major research department. The Department has 
forty-five professorial positions and offers 
undergraduate and graduate (M.S. and Ph.D.) 
degress. Many faculty hold joint research ap¬ 
pointments in the University’s Institute for Ad¬ 
vanced Computer Studies. The prospective ap¬ 
pointment date is approximately July 1,1988. Ap¬ 
plications received by January 15, 1988 will 
receive full consideration. Inquiries, nomina¬ 
tions, and applications should be addressed to: 
Professor John E. Osborn, Chairman of the 
Search Committee, Department of Mathematics, 
University of Maryland, College Park, Maryland 
20742. 

The University of Maryland is an Equal Oppor¬ 
tunity, Affirmative Action Employer. 


128 


COMPUTER 










CONFERENCES 


Editor: Edmund L. Gallizzi, Computer Science Dept., Eckerd College, St. Petersburg, FL 33733; (813) 867-1166 x272 


18th International Multiple-Valued Logic Symposium to be held in Spain 

Henry Huang and David C. Rine 
George Mason University 


Spain’s Universidad de las Islas 
Baleares in Palma de Mallorca has been 
selected as the site of the 18th Interna¬ 
tional Symposium on Multiple-Valued 
Logic. 

Slated for May 24-26, 1988, the sym¬ 
posium will be jointly sponsored by the 
Computer Society of the IEEE, the 
Computer Society’s Technical Commit¬ 
tee on Multiple-Valued Logic, Consejo 
Superior de Investigaciones Cientificas, 
and the host university. 

Additional information on the sym¬ 
posium may be obtained by contacting 
Charles B. Silio, Dept, of Electrical 
Engineering, University of Maryland, 
College Park, MD 20742; (301) 
454-6839. 

One of the highlights of the 1987 
symposium held last May in Boston was 
the presentation of an invited paper 
entitled “Multiple-Valued Minimization 
for PLA Optimization.” Coauthored 
by Richard L. Rudell and Alberto 
Sangiovanni-Vincentelli, it generated a 
great deal of interest and discussion 
among the attendees. 

In the paper, the authors developed 
an algorithm for minimization of 
multiple-valued input, binary-output 
logic functions. They found that these 
functions are an important step in the 
optimization of programmable logic 
arrays (PLAs) and the minimization of 
PLAs with input decoders. 

Their solutions to the output encod¬ 
ing problems rely on efficient solutions 
to the multiple-valued minimization 
problems. They also reported their test 
results to show the importance of 
multiple-valued minimization for PLA 
optimization. 

Among the 48 additional papers 
presented was one entitled “Design of a 
Complementary Pass Gate Network for 
a Multiple-Valued Logic System” by 
Kazuhiro Horie et al. of Tohoku Uni¬ 
versity in Japan. 

In the paper, the authors proposed a 
complementary pass gate (CP-gate) as a 
basic building block for a multiple¬ 
valued logic system. They described a 
CP-gate composed of two pass transis¬ 
tors and a down literal circuit realized 


with multiple-level ion implants. It had 
attractive features such as high density, 
low power dissipation, symmetry, and 
extensibility into an arbitrary MVL sys¬ 
tem. The authors’ work provided a 
solution to the realization of multiple¬ 
valued circuits. 

Over the past several years, the study 
of MVL has mainly focused on theories 
and a number.of special applications. 
MVL researchers consider it an alterna¬ 
tive research tool for computer scien¬ 
tists and engineers to improve today’s 
computer processing and to study fifth 
and sixth generation computers. 

The reason for this is that the real 
world has multiple-valued features. 
Internationally, Japanese and Chinese 


The Second International Conference 
on Computers and Applications, held in 
Beijing in the Peoples Republic of 
China (PRC), was a scholarly meeting 
of computer science researchers and 
professionals. The Computer Society of 
the IEEE and the Chinese Computer 
Federation jointly sponsored the event. 

The conference reflected the fact that 
the Peoples Republic has a number of 
universities that do a good job of 
spreading current technical ideas and 
methodologies. The presentations the 
Chinese made on networks, databases, 
and artificial intelligence were theoreti¬ 
cally up to date, even though their ses¬ 
sions lacked experimental results 
because hardware at their institutions is 
so scarce. 

Four tutorials and more than 150 
papers were presented during the five- 
day June event. Roughly half of the 
papers were authored by computer 
scientists from technical universities in 
Beijing, Xi’an, Shanghai, Harbin, 


MVL researchers have established their 
academic organizations to promote 
studies in this area. In recent years, 
researchers around the world have 
achieved interesting MVL study results 
in circuit design, logic design, artificial 
intelligence, fault-tolerant computing, 
the philosophical aspects of logic, and 
certain special applications. 

During the symposium, David M. 
Miller, former chair of the Technical 
Committee on MVL, was awarded a 
certificate of appreciation for his work 
on the committee, and Robert Swart- 
wout was presented an award by the 
committee for his participation in all of 
the 17 yearly symposiums that have 
been conducted since 1971. 


Wuhan, Hefei, and most of the others 
were written by representatives of 
American institutions. 

My personal participation included 
the presentation of a tutorial on hands- 
on expert systems. The 100-plus who 
attended were as interested in my lec¬ 
ture as they were in the five Macintosh 
computers that were part of my presen¬ 
tation. The Macs, novelties in Beijing, 
were provided by Apple International 
Ltd. of Hong Kong, after considerable 
arrangements were made. 

Following a number of years during 
which free enterprise was suppressed in 
the PRC, its citizens are now encouraged 
to operate their own businesses as an 
adjunct to their government-assigned 
jobs. Even the communes sell their sur¬ 
plus products on the free market. Many 
persons open small shops or restaur¬ 
ants. Computer scientists engage in con¬ 
tract programming, software 
development, and computer engineering 
and manufacturing. They export some 
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products, but the domestic market— 
especially government bureaus and 
communes—provide the important out¬ 
lets for these pioneering entrepreneurs. 

The lack of computers in the PRC 
hinders progress, especially in education 
and business. Americans benefit from a 
modern China which employs western 
technology and participates in the world 
economy. Widespread availability of 
low-cost computing is essential to achiev¬ 
ing this goal. 

Several aspects of introducing this 
technology need to be addressed: 

Visibility. The product has to be 
made known among potential users 
who are leaders in the field. One of the 
most effective ways to spread the word 
is by person-to-person contact at meet¬ 
ings and technical conferences in all 
professions: science, engineering, man¬ 
ufacturing, agriculture, transportation, 
electrical distribution, health, public 
services, architecture, education, 
accounting, communications, etc. 

The presentation of applications by 
professionals would be most welcome. 
There is a meeting almost every week in 
Shanghai and Beijing, and meetings are 
frequently held in other cities. 

Once the contacts have been made, 
individuals interested in pursuing the 
relationships can journey to their host’s 
institution elsewhere in the country. For 
example, to bring the Macintosh and 
the AI software that run on it to the 
computer science departments of Chi¬ 
nese universities, we could call on the 
those who attended my tutorial. They 
could then show these products to their 
colleagues who can use them in their 
teaching and laboratory programs. 
Others might plan to buy hardware and 
software for themselves on their next 
trip to the US. 

Applications. The issues to make 
each computer applicable to the Chi¬ 
nese environment have to be explored. 
The Chinese operating system for the 
Mac is a step in the right direction, but 
the availability of software is the key to 
widespread usage. 

Compilers (Fortran, C, Pascal, Lisp, 
Prolog), graphics, and Chinese 
character processing were mentioned by 
my Chinese hosts as important in their 
work. Applications development soft¬ 
ware, networking, and database 
management and accounting systems 
are also important there. 

Computer games in a nation that 
takes kites and ping pong seriously 
would be popular. The Chinese are 
proficient at writing software and could 
be developing their own products. 

Distribution. Ways have to be found 


to help the Chinese pay.for the machines. 
Local production is another step in the 
right direction. Many of the profes¬ 
sionals at the ICCA made reference to 
their own IBM-PC-oriented hardware 
and software businesses. Some sold 
programming services and software 


In large part, the papers and panels 
presented during the 1987 International 
Test Conference (ITC) in Washington, 
DC, were right in keeping with its 
timely theme of “Integration of Test 
with Design and Manufacturing.” 

The theme was a natural, because 
integrating design and test is an idea 
whose time, at last, has come. Gordon 
Padwick, the program chair, explained 
that this year’s ITC had been scheduled 
earlier than in previous years—just 
prior to Labor Day rather than after the 
holiday. Although some of the first 
papers submitted covered general sub¬ 
jects in the test realm, many directly 
addressed what would emerge as the 
conference theme. 

One of two directly thematic invited 
papers was entitled “Full Stream Test¬ 
ing of Electronic Circuits and Equip¬ 
ment: Status and Opportunities.” 
Authored by Larry Seifert of AT&T, 
the paper described how information in 
the company’s factories doesn’t just 
flow from design to test but that test 
results are fed back to design to 
improve the product. 

In the other theme-oriented paper, 
“Reducing Time to Market—A Major 
Opportunity for the Test Community,” 
author Robert E. Anderson of GenRad 
discussed why design and test are not 
better integrated. He said that local 
optimization in both the design and test 
communities has resulted in the 
designer’s becoming primarily con¬ 
cerned with faster, bigger products, 
while the test engineer has been 
interested in faster, bigger automatic 
test equipment (ATE) to evaluate 
products. 

“You, the market, must demand 
integration,” Anderson told the confer¬ 
ence audience. He said that, if integra¬ 
tion is not yet taking place, it should, 
because the papers presented during the 
conference prove the technology does 
exist. He added that this is especially 
the case in companies with vertically 
integrated design and manufacturing 
capability. 


packages. Several others manufactured 
peripherals, such as networking devices. 
We should encourage this cottage 
industry and make more products and 
ideas available to it. If this is done, the 
ideas will eventually flow in both 
directions. 


AT&T is one such company, and two 
papers dealt with tools designed to link 
design and test of both application spe¬ 
cific integrated circuits (ASICs) and cir¬ 
cuit boards within the firm. “TPG2—An 
Automatic Test Program Generation 
System for Design and Manufacture of 
ASICs” by R.M. Robertson, P.J. Bed- 
narczyk, and Donald Denburg, and the 
DORA2 system, described in a paper by 
Robert Allen, John Malleo-Roach, et 
al., translate simulator output into test 
programs for many ATE. 

The targets of TPG2 are device 
testers, while the primary targets of 
DORA2 are board testers. Both systems 
have been in use at AT&T for many 
years, demonstrating that the difficulty 
of linking design and test is not of a 
technological nature but more a matter 
of commitment. 

Papers from Honeywell, Western 
Digital, GE/RCA, and Sentry described 
similar systems. 

The integration of design and test is 
more than the mechanical translation of 
design data to test data. It also involves 
the influence of testing factors on the 
design of the circuit. This is called 
design for testability (DFT) and 10 of 
the 47 technical ITC sessions dealt with 
DFT. In the past, DFT has been 
primarily used for devices to allow 
access to the internal nodes of increas¬ 
ingly complex integrated circuits and to 
change the extremely difficult sequen¬ 
tial circuit test generation problem into 
the much easier combinational circuit 
test generation problem. 

Now, however, the same problems 
that plagued device test are being 
experienced with board test, where the 
insides of dense boards that use surface 
mount devices are proving difficult or 
impossible to access. 

A new technique, called boundary 
scan, places a shift register around the 
periphery of each chip on a board and 
connects these shift registers into a large 
scan chain. “Boundary-Scan: A Frame¬ 
work for Structured Design-For-Test” 


Integration with design/manufacturing 
a timely 1987 Test Conference theme 
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by Colin Maunder of British Telecomm 
and Frans Beenker of Philips described 
the technique of boundary scan in more 
detail and presented current efforts at 
standardization. Standardization is 
especially important in boundary scan 
because the technique works best if the 
devices of many manufacturers can be 
interconnected on a board in one scan 
chain. 

Boundary scan allows access from the 
board edge connector to every pin of 
every device, a feature that has several 
beneficial effects. For one thing, the 
interconnection between devices can be 
tested without probing from an external 
tester. 

P.T. Wagner of Honeywell described 
some of his experiences in a paper enti¬ 
tled “Interconnect Testing with Bound¬ 
ary Scan.” In “Testing a Board with 
Boundary Scan,” Dirk van de Lagemaat 
and Harry Bleeker of Philips related 
their experiences using boundary scan 
for testing an Integrated Services Digi¬ 
tal Network (ISDN) telephone set. 

Additional papers presented at ITC 
covered test hardware. Some of the 
most interesting papers were three 
describing a 25-MHz tester from IBM. 
This device tester, built because no 
commercial company would bid to pro¬ 
vide one containing the required specifi¬ 
cations, has a minimum pattern width 
of one nanosecond and a driver transi¬ 
tion time of less than 500 picoseconds. 
Many in the standing-room-only 
audience wanted to either obtain one of 
the testers or have one to sell. 

All told, 131 papers were presented 
during the conference. Among them 
were four sessions on automatic test 
generation, four on fault simulation 
and fault analysis, two on artificial 
intelligence, two on fixturing, and two 
on microprocessor test. 

Larry Sumney, president of Semicon¬ 
ductor Research Corp. (SRC), delivered 
the keynote address entitled “The Chal¬ 
lenge to US Technology Leadership.” 

To meet the challenge being posed by 
Japan and other countries, Sumney 
recommended that the US make better 
use of the research and development 
resources it possesses, and share skills 
and cooperation. He said this could 
partially be achieved through the 
resources of SRC and the Sematech 
consortium. 

The keynoter also called for the for¬ 
mation of a national advisory commit¬ 
tee on semiconductor R&D to plan a 
national semiconductor strategy. 

To this observer, the technical con¬ 
tent at the 18th ITC seemed quite high, 
and participation should continue to be 
a must for those involved in testing. 


CALENDAR 


November 1987 


X Conference on Security, Audit, and 
" Control in Distributed Systems and 
Local Networks (ACM), Nov. 15, Los 
Angeles. Contact Dahl A. Gerberick, Ber- 
r, Inc., 14450 Industry Cir., La Mirada, 
CA 90638; (714) 670-7644. 


19th IIA Convention and Exhibition, Nov. 
15-19, Chicago. Contact Carol Simon, Infor¬ 
mation Industry Assoc., 555 New Jersey 
Ave. NW, Suite 800, Washington, DC 
20001; (202)639-8262. 


Wescon 87 (IEEE, ERA), Nov. 17-19, San 
Francisco. Contact Wescon 87, PO 92275, 
Los Angeles, CA 90009-2275; (213) 
772-2965. 


Micro 20, Workshop on Micropro- 
xl? gramming, Dec. 1-4, Colorado 
Springs, Colo. Contact Gearold R. Johnson, 
Center for Computer Assisted Engineering, 
Colorado State University, Ft. Collins, CO 
80523; (303)491-5543. 


Conference on Information Resources 
Management: Standards for Future Informa¬ 
tion Services (NBS), Dec. 3, Gaithersburg, 
Md. Contact Shirley Radack, B151 Technol¬ 
ogy Building, National Bureau of Standards, 
Gaithersburg, MD 20899; (301) 975-2833. 


Eighth Annual International Conference on 
Information Systems (ACM, SIM), Dec. 6-9, 
Pittsburgh. Contact William R. King, 
Graduate School of Business, University of 
Pittsburgh, Pittsburgh, PA 15260; (412) 
648-1587. 


Machine Vision for Process Control and 
Monitoring (SME), Nov. 17-19, Cincinnati. 
Contact Joanne Rogers, Society of Manufac¬ 
turing Engineers, PO 930, Dearborn, MI 
48121; (313) 271-1500, ext. 399. 

ACM South Central Regional Conference, 
Nov. 19-21, Lafayette, La. Contact Terry 
Walker, University of Southwest Louisiana, 
Center for Advanced Computer Studies, PO 
44330, Lafayette, LA 70504-4330; (318) 
232-7013. 


Workshop on Fault Tolerance in Par¬ 
allel and Distributed Computing, Dec. 
7-8, San Diego. Contact Miroslaw Malek, 
Dept, of Electrical and Computer Engineer¬ 
ing, University of Texas, Austin, TX 78712; 
(512)471-5704. 

Performance 87 (ACM, AFCET, IFIP), 

Dec. 7-9, Brussels. Contact G. Latouche, 
Universite Libre de Bruxelles, Campus Plain 
CP212-bd du Triomphe, 1050 Brussels, 
Belgium. 


X International Conference on Informa- 
7 tion Science and Engineering (IERE), 
Nov. 25-27, York, England. Contact R. 
Larry, Institute of Electronic and Radio 
Engineers, 99 Gower St., London WC1E 
6AZ, England, UK; phone 44 (01) 388-3071. 

X Workshop on Computer Vision, Nov. 
" 30-Dec. 2, Miami Beach, Fla. Contact 
Harry Hayman, 738 Whittaker Ter., Silver 
Spring, MD 20901; (301) 434-1990. 


December 1987 


Z2X Third Aerospace Computer Security 
Conference (AIAA), Dec. 8-11, 
Orlando, Fla. Contact Joel Levy, ORI, Inc., 
1375 Piccard Dr., Rockville, MD 20850; 
(301)670-2161. 


International Conference on Frontiers 
in Computing, Dec 9-11, Amsterdam. 
Contact R.P. Van de Reit, PO 4079, 1009 
AB Amsterdam, The Netherlands. 


SIGAda International Conference on Ada 
Programming Language (ACM), Dec. 9-11, 

Boston. Contact Benjamin M. Brosgol, 
Alsys, Inc., 1432 Main St., Waltham, MA 
02154. 


£3^} 1988 Gordon Bell Award for Parallel 
Processing Speedup, entries due Dec. 

I. Contact Gordon Bell Award, IEEE Soft¬ 
ware, 10662 Los Vaqueros Cir., Los 
Alamitos, CA 90720; (714) 821-8380, (503) 
754-3273. 

X Eighth Real-Time Systems Symposium, 
" Dec. 1-3, San Jose. Contact Kang G. 
Shin, Dept, of Electrical Engineering and 
Computer Science, University of Michigan, 
Ann Arbor, MI 48109-2122; (313) 763-0391. 


|£3^} Winter Simulation Conference, Dec. 
xsz 14-16, Atlanta. Contact Hank Grant, 
Factrol, Inc., PO 2569, West Lafayette, IN 
47906; (317)463-3637. 


Eighth International Conference on Com¬ 
puting Methods in Applied Sciences and 
Engineering (INRIA), Dec. 14-18, Versailles, 
France. Contact INRIA, Service des Rela¬ 
tions Exterieures, Bureau des Colloques, 
Domaine de Voluceau, Rocquencourt, BP 
105, 78153 Le Chesnay Cedex, France; 
phone 33 (1) 39-63-56-00. 


November 1987 


131 










January 1988 


£3)j HICSS 88, 21st Hawaii International 
Conference on System Sciences, Jan. 

5-8, Kailua-Kona, Hawaii. Contact Ralph H. 
Sprague, Jr., Decision Sciences Dept., Uni¬ 
versity of Hawaii, 2404 Maile Way, E-303, 
Honolulu, HI 96822; (808) 948-7430. 

Simulation in Engineering Education Con¬ 
ference, Jan. 7-8, San Diego. Contact Soci¬ 
ety for Computer Simulation, PO 17900, San 
Diego, CA 92117; (619) 277-3888. 

Third Technical Symposium on Opto- 
electronics and Laser Applications in 
Science and Engineering (SP1E), Jan. 10-15, 

Los Angeles. Contact Jane Lybecker, SPIE, 
PO 10, Bellingham, WA 98227; (206) 
676-3290. 

ZZ^, Annual IEEE Design Automation 
^87 Workshop, Jan. 13-15, Apache Junc¬ 
tion, Ariz. Contact Walling Cyre, Control 
Data, HQM 173, Box 1249, Minneapolis, 

MN 55440; (612) 853-2692. 

15th SIGAct, SIGPlan Symposium on Prin¬ 
ciples of Programming Languages (ACM), 
Jan. 13-15, San Diego. Contact Jeanne Fer- 
rante, IBM Hawthorne H2-B54, Box 218, 
Yorktown Heights, NY 10598; (914) 
789-7529. 

Third Conference on Hypercube Concurrent 
Computers and Applications, Jan. 19-20, 

Pasadena, Calif. Contact Patricia McLane, 
Jet Propulsion Laboratory, MS 180-205, 
Pasadena, CA 91109; (818) 354-5556. 

Workshop on High-Level Synthesis 
W (ACM), Jan. 24-27, Orcas Island, 
Wash. Contact Ewald Detjens, 1820 Carle- 
ton St., Berkeley, CA 94703; (415) 849-2020. 

International Workshop on Software Ver¬ 
sion and Configuration Control (GI), Jan. 
27-29, Grassau, West Germany. Contact 
Peter Feiler, SEI, Carnegie Mellon Univer¬ 
sity, Pittsburgh, PA 15213; (412) 268-7790. 

Second Conference on Computer 
^57 Workstations (ACM), Jan. 31-Feb. 3, 
Santa Clara, Calif. Contact Patrick Mantey, 
335A Applied Science Bldg., Dept, of Com¬ 
puter Engineering, University of California 
at Santa Cruz, Santa Cruz, CA 95064; (408) 
429-2158. 


February 1988 

Cairo International Computer Conference 
(IASTED), Feb. 1-3, Cairo. Contact 
Secretariat, PO 354, CH-8053, Zurich, Swit¬ 
zerland. 

ZZ^j Fourth International Conference on 
v*7 Data Engineering, Feb. 1-5, Los 
Angeles. Contact Benjamin W. Wah, Dept, 
of Electrical and Computer Engineering, 
University of Illinois, Urbana, IL 61801; 
(217)333-3516. 


Multiconference 88 (SCS), Feb. 3-5, San 
Diego. Contact Society for Computer Simu¬ 
lation, PO 17900, San Diego, CA 92117; 
(619)277-3888. 

Second Conference on Applied Natural Lan¬ 
guage Processing (ACL), Feb. 9-12, Austin, 
Texas. Contact Donald Walker, Bell Com¬ 
munications Research, 445 South St., MRE 
2A379, Morristown, NJ 07960; (201) 
829-4312. 

Winter Unix Technical Conference (Usenix), 
Feb. 9-12, Dallas. Contact Usenix Assoc. 
Conference Office, PO 385, Sunset Beach, 
CA 90742; (213) 592-1381. 

CSC 88, 16th Annual Computer Science 
Conference (ACM), Feb. 23-25, Atlanta. 
Contact Lucio Chiaraviglio, School of Infor¬ 
mation and Computer Science, Georgia 
Institute of Technology, Atlanta, GA 30332; 
(404) 894-3152. 

Vision Guidance for Robotic Systems 
(SME), Feb. 23-25, Cincinnati. Contact 
Joanne Rogers, Society of Manufacturing 
Engineers, 1 SME Dr., Dearborn, MI 48121; 
(313)271-1500. 

Tenth National Computer Conference 
(IEEE), Feb. 28-March 2, Jeddah, Saudi 
Arabia. Contact Athar Javaid, IEEE, PO 
8900, Jeddah 21492, Saudi Arabia. 

Symposium on Information Systems as a 
Resource to Support Managerial Decision- 
Making, Feb. 29-March 3, Sydney, Austra¬ 
lia. Contact IFIP, 3 rue de Marche, 
CH-1204, Geneva, Switzerland. 

Compcon Spring 88, Feb. 29-March 4, 

San Francisco. Contact Hasan al- 
Khatib, Dept, of Electrical Engineering and 
Computer Science, University of Santa 
Clara, Santa Clara, CA 95053; (408) 
554-4485. 


March 1988 

Southcon 88, March 8-10 (IEEE, ERA), 
Orlando, Fla. Contact Southcon 88, 8110 
Airport Blvd., Los Angeles, CA 90045; (213) 
772-2965. 

ZZ^t 1988 International Zurich Seminar on 
\S7 Digital Communications, March 8-11, 

Zurich. Contact Secretariat IZS 88, c/o P. 
Gunzburger, Hasler AG, TDS, Belpstrasse 
23, CH-3000 Bern 14, Switzerland; phone 41 
(31)63-28-08. 

Sixth National Conference on Ada Technol¬ 
ogy, March 14-17, Washington, DC. Con¬ 
tact A1 Rodriguez, US Army Communi- 
cations-Electronics Command, AMSEL- 
RD-LC-ASST-1A, Fort Monmouth, NJ 
07703;(201)532-4725. 

ZZ^t Fourth International Conference on 
Artificial Intelligence Applications, 
March 14-18, San Diego. Contact AI Con¬ 


ference, Computer Society, 1730 Mas¬ 
sachusetts Ave., NW, Washington, DC 
20036-1903; (202)371-1013. 

International Conference Extending Data 
Base Technology (AICA, GI, AFCET, 

BCS), March 14-18, Venice, Italy. Contact 
Joachim W. Schmidt, Universitat Frankfurt, 
Fachbereich Informatik, Dantestrasse 9, D 
6000 Frankfurt 1, West Germany; phone (49) 
69-7988101. 

Seventh IEEE Phoenix Conference on Com¬ 
puters and Communications, March 16-18, 

Scottsdale, Ariz. Contact Carl Ryan, Mo¬ 
torola GEG, 2501 S. Price Rd., Chandler, 

AZ 85248-2899; (602) 732-3074. 

21st Simulation Symposium (SCS, IMACS), 
March 16-18, Tampa, Fla. Contact Alfred 
Jones, Computer Science Dept., Florida 
Atlantic University, Boca Raton, FL 33431; 
(305) 393-3675. 

Compstan 88, Computer Standards 
N57 Conference, March 21-24, Arlington, 
Va. Contact James Hall, US Dept, of Com¬ 
merce, National Bureau of Standards, Tech¬ 
nology Bldg. 225, Rm. B266, Gaithersburg, 
MD 20899; (301)975-3273. 

RIAO 88, User-Oriented Content-Based Text 
and Image Handling Conference (AFIPS), 
March 21-24, Cambridge, Mass. Contact 
RIAO 88, Conference Service Office, Mas¬ 
sachusetts Institute of Technology, Bldg. 7, 
Rm. Ill, Cambridge, MA02139; or CID, 36 
bis rue Ballu, 75009, Paris, France. 

Sixth IEEE VLSI Test Workshop, March 

22- 23, Atlantic City, N.J. Contact Wesley E. 
Radcliffe, IBM East Fishkill, Dept. 277, 

Bldg. 321-5E1, Hopewell Junction, NY 
12533; (914) 894-4346. 

Spring Symposium (AAAI), March 22-24, 

Palo Alto, Calif. Contact American Assoc, 
for Artificial Intelligence, 445 Burgess Dr., 
Menlo Park, CA 94025-3496; (415) 

328-3123. 

ZZ^v COIS 88, Conference on Office Infor¬ 
ms? mation Systems (ACM), March 23-25, 
Palo Alto, Calif. Contact Robert Allen, 
2A-367, Bell Communications Research, 
Morristown, N.J. 07960; (201) 829-4315. 

ZZ^ Extending Database Technology (IASI, 
INRA), March 23-25, Venice, Italy. 
Contact Stefano Ceri, Politecnico di Milano, 
Dipart, di Elektronika, Piazza Leonardo da 
Vinci 32, 20133 Milano, Italy; phone 39 (02) 

23- 67-241. 

Fourth International Conference on Pattern 
Recognition (BPRA, IAPR), March 28-30, 

Cambridge, England. Contact J. Kittler, 
Dept, of Electronic and Electrical Engineer¬ 
ing, University of Surrey, Guildford GU2 
5XH, England, UK. 

ZZN Infocom 88, March 28-31, New 
\57 Orleans. Contact Infocom 88, Com¬ 
puter Society of the IEEE, 1730 Mas¬ 
sachusetts Ave. NW, Washington, DC 
20036-1903; (202) 371-1013. 
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April 1988 


Conference on the Human Dimension in 
Artificial Intelligence, April 6-9, Lexington, 
Ky. Contact Engineering Continuing Educa¬ 
tion, 223 Transportation Research Bldg., 
University of Kentucky, Lexington, KY 
40506-0043; (606) 257-4295. 

International Workshop on Robot Control: 
Theory and Applications (IEE), April 11-12, 

Oxford, England. Contact the Computing 
and Control Division, IEE, Savoy PL, Lon¬ 
don WC2R 0BL; phone 44 (01) 240-1871, 
ext. 330. 


Computer Networking Symposium, 
va? April 11-13, Arlington, Va. Contact 
George K. Chang, 6 Corporation PL, Pis- 
cataway, NJ 08854; (201) 699-3879. 

CompEuro 88, April 11-15, Brussels. 

Contact Jacques Tiberghien, VRIJE 
Universiteit Brussels, Pleinlaan 2, 1050 Brus¬ 
sels, Belgium; phone 32 (02) 641-29-05. 


:e on Software Engineering (ACM), 
April 11-15, Raffles City, Singapore. Con¬ 
tact Tan Chin Nam or Lim Swee Say, 71 
Science Park, Singapore 0511; phone (65) 
772-0200. 


IPC 88, 17th International Programmable 
Controllers Conference (ESD, SMI), April 
12-14, Detroit. Contact IPC 88, 100 Farns¬ 
worth, Detroit, MI 48202; (800) 457-9504. 

Manufacturing International 88 (ASME), 
April 17-20, Atlanta. Contact Meetings 
Dept., American Society of Mechanical 
Engineers, 345 E. 47th St., New York, NY 
10017; (212) 705-7788. 

Eastern Simulation Conference (SCS), April 
18-21, Orlando, Fla. Contact Society for 
Computer Simulation, PO 17900, San 
Diego, CA 92117; (619) 277-3888. 


Sococo 88, Symposium on Software for 
Computer Control (IFAC, IFIP), April 
26-28, Johannesburg, South Africa. Contact 
IFIP, 3 rue de Marche, CH-1204, Geneva, 
Switzerland. 

Second Expert Systems Conference (ESD, 
SMI), April 26-28,, Dearborn, Mich. Con¬ 
tact Engineering Society of Detroit, 100 
Farnsworth, Detroit, MI 48202; (800) 
457-9504. 


May 1988 

19th Pittsburgh Conference on Modeling 
and Simulation (IEEE, ISA, SCS), May 5-6, 
Pittsburgh. Contact William G. Vogt or 
Marlin H. Mickle, Modeling and Simulation 
Conference, 348 Benedum Engineering Hall, 
University of Pittsburgh, Pittsburgh, PA 
15261. 

Workshop on Parallel and Distributed 
Debugging (ACM), May 5-6, Madison, Wis. 
Contact Bart Miller, Computer Sciences 
Dept., University of Wisconsin, 1210 W. 
Dayton St., Madison, WI 53706; (608) 
263-3378. 

38th Electronic Components Conference 
(IEEE, El A), May 9-11, Los Angeles. Con¬ 
tact Electronic Industries Assoc., 2001 Eye 
St. NW, Washington, DC 20006. 

Fifth Workshop on Real-Time Operat¬ 
es? ing Systems, May 12-13, Washington, 
DC. Contact John A. Stankovic, Dept, of 
Computer and Information Science, Univer¬ 
sity of Massachusetts, Amherst, MA 01003; 
(413) 545-0720. 

Fourth International Software Process 
Workshop (IEEE, ACM), May 11-13, 
Devon, England. Contact Leon Osterweil, 
Computer Science Dept., University of 
Colorado, Campus Box 430, Boulder, CO 
80309; (303) 492-8787. 


llth IEEE Workshop on Design for 
vs? Testability, April 19-22, Vail, Colo. 
Contact T.W. Williams, IBM Corp., PO 
1900, Dept. 67A/021, Boulder, CO 
80301-9191; (303) 924-7692. 


CHI 88, Conference on Human Factors in 
Computing Systems (ACM), May 15-19, 
Washington, DC. Contact Gail A. Chumura, 
5214 Monroe Dr., Springfield, VA 22151; 
(703) 750-9401. 


International Conference on Electronic Pub¬ 
lishing, Document Manipulation, and 
Typography (INRIA), April 20-22, Nice, 
France. Contact INRIA, Service des Rela¬ 
tions Exterieures, Bureau des Colloques, 
Domaine de Voluceau, Rocquencourt—BP 
105, F-78153 Le Chesnay Cedex, France. 


£3^ Second International Conference on 
\8? Expert Database Systems, April 25-28, 

Tysons Corner, Va. Contact Edgar H. 
Sibley, George Mason University, ICSE 
Dept., 4400 University Dr., Fairfax, VA 
22030. 


IEEE International Conference on Robotics 
and Automation, April 25-29, Philadelphia. 
Contact Harry Hayman, 738 Whitaker Ter¬ 
race, Silver Spring, MD 20901; (301) 
434-1990. 


Second Symposium on Space C 3 (AFCEA), 
May 16-19, Annapolis, Md. Contact Randy 
Crawford/DQ, IIT Research Institute, 185 
Admiral Cochrane Dr., Annapolis, MD 
21401; (301) 224-2295. 

International Conference on Rural Telecom¬ 
munications (IEE), May 23-25, London. 
Contact Conference Services Dept., Institu¬ 
tion of Electrical Engineers, Savoy PL, Lon¬ 
don WC2R OBL, UK; phone (44) 
01-240-1871. 

Third International IEEE Conference 
va? on Ada Applications and Environ¬ 
ments, May 23-26, Manchester, N.H. Con¬ 
tact Derek S. Morris, Dept, of Electrical 
Engineering and Computer Science, Stevens 
Institute of Technology, Hoboken, NJ 
07730; (210) 420-5606. 


SID 88, May 23-27, Anaheim, Calif. Contact 
James N. Price, Naval Ocean Systems Cen¬ 
ter, Attn.: Code 713, San Diego, CA 92152; 
(619)225-2665. 


18th International Symposium on 
V3? Multiple-Valued Logic, May 24-26, 

Madrid, Spain. Contact Enric Trillas, Inves- 
tigaciones Cientificas, Serrano 117, 
28006-Madrid, Spain; phone 34 (91) 
62-16-264. 


SIGMetrics Conference on Measurement and 
Modeling of Computer Systems (ACM), 

May 24-27, Santa Fe, N.M. Contact Connie 
U. Smith, L & S Computer Technology, 

1114 Buckman Rd., Santa Fe, NM 87501; 
(505) 988-3811. 

CG International 88 (CGS, BCS), May 
24-27, Geneva. Contact N. Magnenat- 
Thalmann, MIRALab HEC, 5255 Decelles, 
Montreal, Canada H3T 1V6. 


International Conference on Systolic 
v5? Arrays, May 25-27, San Diego. Con¬ 
tact Keith Bromley, Code 741-T, Naval 
Ocean Systems Center, 271 Catalina St., San 
Diego, CA 92152; (619) 225-7008. 


International Workshop on Artificial Intelli¬ 
gence for Industrial Applications (IEEE, 
SICE), May 25-27, Hitachi, Japan. Contact 
Takao Sasayama, Technology Planning 
Group, Hitachi America Ltd., 50 Prospect 
Ave., Tarrytown, NY 10591-4698; (914) 
332-5800. 


15th IFAC Workshop on Real-Time Pro¬ 
gramming, May 25-27, Valencia, Spain. 
Contact WRTP 88, Grupo de Informatica 
Industrial—DSIC/DISCA, Universidad 
Politecnica de Valencia, PO 22012, E-46071 
Valencia, Spain; phone (34) 6-360-40-41. 


Eurocrypt 88, Workshop on the Theory and 
Application of Cryptologic Techniques 
(IACR), May 25-27, Davos, Switzerland. 
Contact Paul Schobi, Ltd., Althardstr. 70, 
CH-8105 Regensdorf, Switzerland. 


jfijt 15th International Symposium on 
va? Computer Architecture (ACM), May 
30-June 2, Honolulu. Contact H.J. Siegel, 
Supercomputing Research Center, 4380 
Forbes Blvd., Lanham, MD 20706; (301) 
731-3700. 


NCC 88, National Computer Confer¬ 
va? ence (Computer Society, AFIPS, 
ACM, DPMA, SCS), May 31-June 3, Los 
Angeles. Contact AFIPS, 1899 Preston 
White Dr., Reston, VA 22091; (703) 
620-8900. 


June 1988 

SIGMOD 88, Conference on Management of 
Data (ACM), June 1-3, Chicago. Contact 
Dina Bitton, Dept, of Electronic Engineering 
and Computer Science, University of Illinois, 
PO 4348, Chicago, IL 60680, (312) 996-5492, 
or Peter Scheuermann, Dept, of Electrical 
Engineering and Computer Science, North¬ 
western University, Evanston, IL 60201; 
(312)491-7141. 
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Z2N First International Conference on 

Industrial and Engineering Applica¬ 
tions of Artificial Intelligence and Expert 
Systems, June 2-3, Tullahoma, Tenn. Con¬ 
tact Richard Roberds, University of Tennes¬ 
see Space Institute, Tullahoma, TN 37388; 
(615) 455-0631. 

Conference on Computer Vision and 
^*7 Pattern Recognition, June 5-9, Ann 

Arbor, Mich. Contact Ramesh Jain, Dept, 
of Electrical Engineering and Computer 
Science, 3215 EECS Bldg., University of 
Michigan, Ann Arbor, MI 48109-2122; (313) 
763-0387. 

Third Israel Conference on Computer 
KS7 Systems and Software Engineering 
(Israel chapter of the Computer Society and 
Information Processing Assoc, of Israel), 
June 6-7, Tel Aviv. Contact Jonah Z. Lavi, 
PO 50432, Tel Aviv 61500, Israel; phone 
(972)3-664825. 


DAC 88, 25th ACM/IEEE Design 
Automation Conference, June 12-15, 

Anaheim, Calif. Contact Design Automation 
Conference, Pat Pistilli, MP Associates, Inc. 
7490 Clubhouse Rd., Suite 102, Boulder, CO 
90301; (303) 530-4333. 

ICC 88, International Conference on Com¬ 
munications (IEEE), June 12-15, Philadel¬ 
phia. Contact Gary Ridge, Bell of Pennsylvania, 
15th Floor, 1 Pkwy., Philadelphia, PA 
19102; (215) 466-8709 or ICC-88, c/o IEEE 
Office, Moore School of Electrical Engineer¬ 
ing, Rm. 209, University of Pennsylvania, 
Philadelphia, PA 19104; (215) 898-8106. 

Third International Workshop of the 
Bellman Continuum (INRIA), June 13-14, 
1988, Sophia-Antipolis, France. Contact 
Prof. A. Blaquiere, Universite de Paris VII, 
Laboratoire d’Automatique Theorique, Tour 
14-24, 2 Place Jussieu—75251 Paris Cedex 
05, France. 


27-30, Tokyo. Contact Yasuo Komamiya, 
2-4-8 Kikuna, Kohoku Ku, Yokohama 222, 
Japan; phone (81) 044-911-8181. 

Fifth International Conference on Dielectric 
Materials, Measurements, and Applications, 
June 27-30, Canterbury, England. Contact 
Conference Services Dept., Institution of 
Electrical Engineers, Savoy PI., London 
WC2R OBL, UK. 

Third International Conference on Data and 
Knowledge Bases, June 28-30, Jerusalem. 
Contact Databases Conference Secretariat, 
PO 29313, Tel Aviv 65121, Israel; phone 
(972)03-654541. 


Second International Conference on Vector 
and Parallel Computing (SIAM), June 6-10, 

Tromso, Norway. Contact Berit Hilt, Bergen 
Scientific Center, Allegaten 36, 5000 Bergen, 
Norway. 

ISCAS 88, IEEE International Symposium 
on Circuits and Systems, June 7-9, Espoo, 
Finland. Contact Pekka Heinonen, Tampere 
University of Technology, Computer Sys¬ 
tems Laboratory, PO 527, SF-33101 Tam¬ 
pere, Finland, or Olli Simula, Helsinki 
University of Technology, Dept, of Techni¬ 
cal Physics, SF-02150 Espoo 15, Finland. 

Eighth International Symposium on Pro¬ 
tocol Specification, Testing, and Verification 
(IFIP), June 7-10, Atlantic City, N.J. Con¬ 
tact Sudhir Aggarwal, Bell Communications 
Research, 435 South St., Morristown, NJ 
07960; (201) 829-4477; or Krishan Sabnani, 
AT&T Bell Laboratories, 600 Mountain 
Ave., Murray Hill, NJ 07974; (201) 

582-5740. 


Fifth International Conference on Testing 
Computer Software (DPMA), June 13-16, 

Washington, DC. Contact US Professional 
Development Institute, 1734 Elton Rd., Suite 
221, Silver Spring, MD 20903; (301) 
445-4400. 

Eighth International Conference on 
Distributed Computing Systems, June 
13-17, San Francisco. Contact Computer 
Society of the IEEE, 1730 Massachusetts 
Ave. NW, Washington, DC 20036-1903; 
(202)371-1013. 

17th Mumps Users’ Group Meeting, June 
13-17, New Orleans. Contact Mumps Users’ 
Group, 4321 Hartwick Rd., Suite 510, Col¬ 
lege Park, MD 20740; (301) 779-6555. 

Prolomat 88, Seventh International Confer¬ 
ence on Software for Discrete Manufactur¬ 
ing (IFAC), June 14-17, Dresden, West 
Germany. Contact IFIP, 3 rue de Marche, 
CH-1204, Geneva, Switzerland. 


July 1988 

1988 International Conference on Supercom¬ 
puting (ACM, INRIA), July 4-8, Saint Malo, 
France. Contact one of the following: 

C.D. Polychronopoulos, Center for Super¬ 
computing, University of Illinois. 104 S. 
Wright St., Urbana, IL 61801 (North and 
South America); W. Jalby, INRIA, BP 105 
78153, Le Chesnay Cedex, France (Europe, 
Middle East, Africa); or H. Terada, Dept, of 
Electronic Engineering, Osaka University, 
Yamadaoka, 2-1 Suita, Osaka, Japan 565 
(Japan and the Far East). 


Conference on the Role of Artificial Intelli¬ 
gence in Databases and Information Systems 
(IFIP), July 4-8, Canton, China. Contact 
Robert Meersman, Infolab, K.U. Brabant, 
Postbus 90153, NL-5000 Le Tilburg, The 
Netherlands, phone 31 (13) 66-24-30. 


26th Assoc, for Computational Linguistics 
Meeting, June 7-10, Buffalo, N.Y. Contact 
William J. Rapaport, Dept, of Computer 
Science, State University of New York, 
Buffalo, NY 14260; (716)636-3193. 

ECCE 88, European Conference on Com¬ 
munication and Enterprise (AFCET), June 
7-10, Paris. Contact Conference Secretariat, 
ECCE 88, 156, boulevard Pereire, 75017 
Paris, France; phone (33) 1-47-66-24-19. 


£3^1 Symposium on Engineering of 

Computer-Based Medical Systems, 
June 8-10, Minneapolis, Minn. Contact John 
M. Long, 2829 University Ave. SE, Suite 
408, Minneapolis, MN 55414; (612) 

627-4850. 


Eighth International Conference on Analysis 
and Optimization of Systems (INRIA), June 
8-10, Antibes, France. Contact INRIA, Ser¬ 
vice des Relations Exterieures, Bureau des 
Colloques, Domaine de Voluceau, Rocquen- 
court, BP 105, 78153 Le Chesnay Cedex, 
France; phone 33 (1) 39-63-56-00. 


NECC 88, Ninth National Educational Com¬ 
puting Conference (ACM), June 15-17, 

Dallas. Contact NECC 88, International 
Council for Computers in Education, Uni¬ 
versity of Oregon, 1787 Agate St., Eugene, 
OR 97403-9905; (503) 686-4414; or James L. 
Poirot, Computer Science Dept., North 
Texas State University, PO 13886, Denton, 
TX 76203-3886; (817) 565-2818. 

IEEE International Symposium on Informa¬ 
tion Theory, June 19-24, Kobe, Japan. Con¬ 
tact Shu Lin, Dept, of Electrical 
Engineering, University of Hawaii at 
Manoa, Holmes Hall 483, 2540 Dole St., 
Honolulu, HI 96822; or Suguru Arimoto, 
Faculty of Engineering Science, Osaka Uni¬ 
versity, Toyonaka, Osaka 560, Japan. 

International Conference on Private Switch¬ 
ing Systems and Networks (IEE), June 21- 

23, London. Contact Conference Services 
Dept., Institution of Electrical Engineers, 
Savoy Pl„ London WC2R OBL, UK 


9 


18th International Symposium on 
Fault-Tolerant Computing, June 


Second Conference on Software Engineering 
(IEE, BCS), July 11-15, Liverpool, England. 
Contact Conference Services, IEE, Savoy 
Place. London WC2R OBL, England, UK. 


12th IMACS World Congress on Scientific 
Computation, July 18-22, Paris. Contact 
Jean-Marc David, Laboratoires de Marcous- 
sis, Computer Science Division, Route de 
Nozay, 91460, Marcoussis, France. 


* and Verification, July 19-21, Alberta, 
Canada. Contact Lee White, Dept, of Com¬ 
puter Science, University of Alberta, 
Edmonton, Alberta, Canada T6G 2H1; (403) 
432-4589. 


ECCE 88, European Conference on Com¬ 
puters and Education, July 24-29, Lausanne, 
Switzerland. Contact IFIP, 3 rue de Marche, 
CH-1204, Geneva, Switzerland. 


Summer Computer Simulation Conference 
(SCS), July 25-27, Seattle. Contact Society 
for Computer Simulation, PO 17900, San 
Diego, CA 92117; (619) 277-3888. 


134 


COMPUTER 











CALL FOR PAPERS 


1988 INTERNATIONAL CONFERENCE 


ON SUPERCOMPUTING 


JULY 4-8, 1988-SAINT MALO, FRANCE 

Sponsored by ACM, in cooperation with INRIA, 
IRISA, Center for Super computing Research and 
Development, Computer Technology Institute, Pur¬ 
due Center for Vector and Parallel Processing, and 
the Information Society of Japan. 


CONFERENCE CHAIRMAN PROGRAM CHAIRMAN 
D. J. Kuck, Illinois J. Lenfant, Rennes 

PROGRAM VICE-CHAIRMEN 
Europe & Middle East: W. Jalby, INRIA 

Japan & the Far East: H. Terada, Osaka 

North & South America: C. D. Polychronopoulos, Illinois 

Local Arrang.: B. Philippe, IRISA Publicity: J. Erhel, IRISA 

Proceedings: D. DeGroot, TI Secretary: Y. Jegou, IRISA 

Treasurer: M. Raynal, IRISA Registration: P. Quinton, IRISA 

COMMITTEES 

EUROPE: I.Duff, HARWELL, E.Gelenbe, ISEM, W.Giloi, GMD/TUB, J.Gurd, Manchester, 
F.Hossfeld, KFA, P. Lallemand, DRET, A.Lichnewsky, INRIA, T.Papatheodorou, CTI, R. Per- 
rot, Belfast, U. Trottenberg, Suprenum, 

JAPAN: M. Amamiya, NTT, K. Fuchi, Y. Muraoka, Waseda, H. Tanaka, Tokyo, T. Yba, EL 

USA: F. Allen, IBM, Arvin, MIT, E. S. Davidson, Illinois, J. Dongarra, Argonne, G. Fox, Cal¬ 
tech, D. Gannon, Indiana, E. N. Houstis, Purdue, K. Kennedy, Rice, G. Pfister, IBM, J. Rice, 
Purdue, Y. Saad, Illinois, J. Sopka, DEC 

INVITED SPEAKERS 

G.Bell, NSF R.Glowinski, INRIA/Houston H.T.Kung, CMU 

C. Ledbetter, ETA G.Paul, IBM A.Sameh, Illinois 

SCOPE 

Topics of interest include (but are not limited to) supercomputer architectures, technology, software (com¬ 
pilers, operating systems), performance evaluation, languages, parallel numerical analysis, applications. 

PAPERS 

Deadline for submission fo contributed papers is February 1, 1988. Send Five copies of complete paper 
to W. Jalby, INRIA, BP 105 78153, LE CHESNAY CEDEX, FRANCE (Europe, Middle East, Africa), or 
to H. Terada, Dept, of Electronic Engineering, Osaka Univesrity, Yamadaoka, 2-1 Suita, Osaka, JAPAN 
565 (Japan and the Far East), or to C. Polychronopoulos, Center for Supercomputing, University of 
Illinois, 104 S. Wright St., Urbana, Illinois 61801, USA (North and South America). Proceedings will be 
published by ACM. 
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The Fourth International Conference on 
Data Engineering 


February 1-5, 1988 

Los Angeles Airport Hilton and 
Towers 

Los Angeles, Ca. 

ADVANCE 
PROGRAM 

Sponsored by the Computer Society of the IEEE 



Scope 

Data Engineering is concerned with the semantics and structuring of data in information systems design, development, 
management and use. It encompasses both traditional applications and issues, and emerging ones. The purpose of this conference 
is to provide a forum for the sharing of practical experiences and research advances from an engineering point of view among 
those interested in automated data and knowledge management. Our expectation is that this sharing will enable future 
information systems to be more efficient and effective, and future research to be more relevant and timely. 

Invitation 

The conference should prove to be well worth attending. There will be three days of general sessions having 66 papers and five 
panels in three tracks, with a keynote speaker each day. A fourth track of vendor presentations will complement the research 
tracks. Nine tutorials each provide an opportunity for intensive exposure to a data engineering topic. Ample time will be 
available for meaty discussions. Come and join us. 


General sessions: February 2-4, 1988 


Object-Oriented Databases I 
Object-Oriented Databases II 
Knowledge-Based Systems I 
Knowledge-Based Systems II 
Database Tools 

Clustering and Indexes 
Recursive queries and logic 
Hashing II 


Transaction Processing I 
Distributed Systems I 
Parallel Techniques for Databases 
Integrity and Restructuring 
Hashing I 

Concurrency Control 
Searching Techniques 
Multi-Databases 


File Allocation 

Material Properties Information Systems 
Database Standards: too soon or essential? 
Query Optimization 

Is "object-oriented " the final solution to 
DBMS problems? 

The role of databases in model management 
Transaction Processing II 
Can we meaningfully integrate drawing, 
text.image and voice with structured data? 


Plenary sessions 

John L. McCarthy, U.C. Berkeley, Knowledge engineering or engineering information: do we need new tools? 

Michael Stonebraker, U.C. Berkeley, Future trends in database systems 

Frederick Hayes-Roth, Teknowledge, Engineering, organizing and managing knowledge: 

meeting requirements for practical AI systems 
John V. Carlis, U. of Minnesota, What have we learned? 


For a complete advanced program contact: 
Data Engineering Conference 
c/o Computer Society of the IEEE 
1730 Massachusetts Ave. N.W. 
Washington, DC 20036-1903 
For other information contact the general 


General Chair: Benjamin Wah, U. of 
Illinois, 217-333-3516, or 
wah@aquinas.csl.uiuc.edu 
Program Chair: John Carlis, U. of 
Minnesota, 612-625-6092, or 
carlis@umn-cs.umn.edu 
Tutorial Chair: Amit Sheth, UNISYS 


The fifth Data Engineering Conference is 
coming in February, 1989 with John 
Carlis as general chair and Richard 
Shuey, RPI, as program chair. Prepare 
now. Papers will be due June 15,1988. 
Look for an ad in April’s IEEE COMPUTER 
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The Fourth International Conference on Data Engineering 


Vendor Track 

There will be a DBMS vendor track. Vendor representatives 
will focus on what sets their products apart, and on what we 
can expect from them in the future. 


Tutorials 

Monday, February 1 

1. ) 8:30 -5:00 Philip A. Bernstein, Transaction Processing 
Systems 

2. ) 8:30-12:00 M. Tamer Ozsu, Distributed Database 
Operating Systems 

3. ) 1:30-10:00 Saeed Rahimi, Distributed DBMS: Principles 
and Architecture 

4. ) 6:30-10:00 John V. Carlis, Principles of Physical 
Database Design: Models, Methods, Tools 

5. ) 6:30-10:00 Benjamin Wah, Neural Networks and their 
applications 


Tuesday, February 2 

6. ) 7:00-10:00 David S. Reiner, Automated Support for 
Database Design 

Wednesday, February 3 

7. ) 7:00-10:00 James P. Larson, User Interface Management 
System 

Friday, February 5 

8. ) 8:30-12:00 Jim Diederich and Jack Milton, Introduction 
to Object Oriented Concepts: Smalltalk and Database 

9. ) 8:30-12:00 Marshall Abrams, Information Security: 
Secrecy and Integrity 


Hotel and Airline Information 

Los Angeles Airport Hilton and Towers Directions to the hotel: 


5711 W. Century Blvd. 

Los Angeles, CA 90045-5631 
213-410-4000 

for reservations call: 1-800-HILTONS 
Room rates: $78.00 single or double 


Flying: From the baggage claim areas exit 
to the street. Go to a middle island, green 
pick up sign to meet the hotal van. 

Driving: exit 1405 going West on Century 
Blvd for 1 mile. 


We have arranged with TWA via 
Thunderbird Travel Service for special 
air fares. Call TWA at 1-800-325-4933 
(1-800-392-1673 in MO.) or the agency 
at 1-805-987-5087. Refer to Profile # 
9913721. 


Conference registration will be available in the hotel's Marina Room 


Data Engineering Registration Form 


February 1-5, 1988 


Make checks payable to 'Data Engineering Conference', or l 
out the credit card information below. Send completed forms t 
Data Engineering Conference 
c/o Computer Society of the IEEE 
1730 Massachusetts Ave. N.W. 

Washington, DC 20036-1903 


Please check the tutorial(s) that you are attending: 

_1.) Bemstein(full) _6.) Reiner(half) 

_ 2.) Ozsu (half) 7.) Larson(half) 

_ 3.) Rahimi(full) 8.) Diederich and 

_ 4.) Carlis(half) Milton(half) 

5.) Wah (half).9.) Abrams(half) 


Conference 
Half day tutorial 
Full day tutorial 


Conference 
Half day tutorial 
Full day tutorial 


Advanced registration 
prior to 1/8/1988 
Member Non-member Student 

$200 $250 $40 

90 110 40 

160 200 40 

after 1/8/1988 

Member Non-member Student 

$240 $300 $40 

110 135 40 

200 250 40 


IEEE or IEEE C S no. phone # 


name affiliation 




city/state/zip/country 


Conference amount $. 

Half day tutorial fee(s) $_ 
Full day tuttorial fee(s) $. 


credit card name/number/expiration date 


TOTAL ENCLOSED $. 


cardholder signature 


Notes: Conference registration fee includes admission to the technical sessions, one copy of the conference proceedings (except 
students), break refreshments, and reception. Refunds, less $15 handling fee, will be made if requested in writing by January 
19,1988. Tutorial registration includes one copy of tutorial notes. 
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Call for referees for Computer 


Referees are sought for special issues of 
Computer that will cover the following 

• laser communication technology and 
systems 

• computer-integrated manufacturing 

• national computer policies—the com¬ 
puter industry in an international 
context 

• innovative printer technology 

• storage technology 

• concurrent systems: the hardware, 
production, maintenance, and software 

• emerging technologies for computer 


component, hardware, and software 
design and production 

• high-performance CAD/CAM, 
engineering/scientific, and 
programming work stations 

• computers in automobiles 

• computers in the entertainment and 
advertising industries 

• real-time systems 

• Videotext—has the vision failed? 

Persons interested in serving as referees are 
asked to circle Reader Service Number 195 
on the Reader Service Card at the back of 
this magazine and to send the card to the 
Reader Service Inquiries Dept. 


IEEE Expert is seeking materials for 
publication. Articles on technology 
and AI applications should be submitted to 
David Pessel, Editor-in-Chief, BP America, 
4440 Warrensville Center Rd., Cleveland, 

OH 44128.Conference coverage, short sub¬ 
jects and papers on PCs, products, and 
resources should be sent to Henry Ayling, 
Managing Editor, IEEE Expert, 10662 Los 
Vaqueros Cir., Los Alamitos, CA 90720. 
Book reviews should be addressed to K.S. 
Shankar, Associate Editor, Federal Systems 
Division, IBM Corp., 3700 Bay Area Blvd., 
Houston, TX 77058. 

Artificial Intelligence and Education: This 
journal seeks both articles and proposals for 
issues devoted to specific topics. Authors in 
the US and Far East should contact Elliott 
Soloway, Dept, of Computer Science, Yale 
University, New Haven, CT 06520. Those in 
Europe should contact Masoud Yazdani, 
Dept, of Computer Science, Prince of Wales 
Rd., University of Exeter, Exeter EX4 4PT, 
England, UK. 

Computer Society of the IEEE Techni¬ 
cal Committee on Computer Educa¬ 
tion: Contributions up to five typewritten 


pages are welcomed for the TCCE newslet¬ 
ter, a forum for the exchange of ideas among 
persons interested in computer education or 
computers in education. News items, short 
articles, and correspondence should be sent 
to Helen Hays, Dept, of Computer Science, 
Southeast Missouri State University, Cape 
Girardeau, MO 63701; (314) 651-2244. 

International Journal for Artificial Intelli¬ 
gence in Engineering: Papers are sought on 
research and development leading to problem¬ 
solving strategies. For information and sub¬ 
mission requirements, contact D. Sriram, 
Dept, of Civil Engineering, Carnegie Mellon 
University, Pittsburgh, PA 15213, or K.J. 
MacCallum, Dept, of Ship and Marine Tech¬ 
nology, Marine Technology Center, 100 
Montrose St., Glasgow, Scotland, UK. 

International Journal of Pattern Recognition 
and Artificial Intelligence: Submit four 
copies of manuscripts to H. Bunke, Univer- 
sitat Bern, Institut fur Informatik und 
Angewandte Mathematik, Langgasstrasse 
51, CH-3012 Bern, Switzerland, or Patrick 
Wang, College of Computer Science, North¬ 
eastern University, 360 Huntington Ave., 
Boston, MA 02115; (617)437-3711. 


Conferences that the Computer Society sponsors or participates in are indicated 
by the Computer Society logo; additional conference sponsors are listed in paren¬ 
theses. Other conferences of interest to our readers are also included. 

For inclusion in Call for Papers or Calendar, submit information six weeks before 
the month of publication (e.g., for the January 1988 issue, send information for 
receipt by Nov. 15,1987, to Calendar Editor, Computer, 10662 Los Vaqueros Cir., 

Los Alamitos,CA 90720. 


International Journal of Computer Applica¬ 
tions in Technology begins publication in 
Spring 1988. Papers are sought for this 
UNESCO-supported journal. Send three 
copies of papers to M.A. Dorgham, The 
Open University, Milton Keynes, MK7 6AA, 
England, UK; phone (44) 09-08-653945. 

FTCS 18, 18th International Sympo- 
sium on Fault-Tolerant Computing: 

June 27-30, 1988, Tokyo. Six copies of 
manuscripts should be submitted by Nov. 15, 
1987, to FTCS 18 Program Committee, PO 
151, Hiroshima Central Post Office, Hiroshima 
730-91, Japan. 

Summer Computer Simulation Conference 

(SCS): July 25-27, 1988, Seattle. Submit 
drafts by Nov. 15, 1987, and complete 
manuscripts by March 15, 1988 to Charles 
A. Pratt, PO 17900, San Diego, CA 92117; 
(619) 277-3888. 

Vision Guidance for Robotic Systems (SME): 
Feb. 23-25, 1988, Cincinnati. Abstracts are 
sought by Nov. 23,1987, addressed to 
Joanne Rogers, Society of Manufacturing 
Engineers, 1 SME Dr., Dearborn, MI 48121; 
(313)271-1500. 


/gjv Fourth IEEE Conference on Artificial 
Intelligence Applications: March 
14-18, 1988, San Diego. Abstracts describing 
ongoing research, demonstration proposals, 
and panel session proposals are sought. Sub¬ 
mit four copies to Elaine Kant or Dennis 
O’Neill, Schlumberger-Doll Research, Old 
Quarry Rd., Ridgefield, CT 06877-4108 by 
Nov. 25, 1987. 


Sixth IEEE VLSI Test Workshop: March 
22-23,1988, Atlantic City, N.J. Abstracts are 
sought by Nov. 27,1987, addressed to 
Mukund Modi, Naval Air Engineering Cen¬ 
ter, ATE Software Center, Code: 92514, 
Lakehurst, NJ 08733; (201) 323-2413/2188. 


® IEEE Software: Articles are sought for 
the special July 1988 issue on fourth- 
generation languages. Eight copies of 
manuscripts are due by Dec. 1, 1987. Con¬ 
tact Ted G. Lewis, editor-in-chief, IEEE 
Software, c/o Computer Science Dept., Ore¬ 
gon State University, Corvallis, OR 97331; 
(503) 754-2744; CSnet lewis@oregon-state; 
Compmail+ t. lewis. 


IEEE Expert: Articles are sought for a 
special issue on artificial intelligence 
research and development for the govern¬ 
ment. Six copies of papers are due by Dec. 1, 
1987 addressed to Jude Franklin, MS 5S4, 
1500 Planning Research Dr., McLean, VA 
22102; (703) 556-1990; or Kamal Kama, 
Computer Communications & Graphics, 823 
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Flagler Dr., Gaithersburg, MD 20878; (301) 
921-0392. 

IEEE International Symposium on Informa¬ 
tion Theory: June 19-24, 1988, Kobe, Japan. 
Papers suitable for 20-minute presentations 
are sought. Submit three copies of summaries 
and abstracts by Dec. 1, 1987, to either Shu 
Lin, Dept, of Electrical Engineering, Univer¬ 
sity of Hawaii at Manoa, Holmes Hall 483, 
2540 Dole St., Honolulu, HI 96822, or 
Suguru Arimoto, Faculty of Engineering 
Science, Osaka University, Toyonaka, Osaka 
560, Japan. 

Second Symposium on Space C 3 (AFCEA): 
May 16-19, 1988, Annapolis, Md. Prospec¬ 
tive authors should contact Randy Craw- 
ford/DQ, IIT Research Institute, 185 
Admiral Cochrane Dr., Annapolis, MD 
21401; (301) 224-2295 by Dec. 1, 1987, and 
submit abstracts by Jan. 9, 1988. Final 
manuscripts are due by April 11,1988. 


University of Waterloo, Waterloo, Ontario, 
Canada N2L 3G1); (2) applications and 
implementations (send to Haran Boral, 
MCC, 3500 W. Balcones Center Dr., Austin, 
TX 78759). 

SID 88, International Symposium, Seminar 
and Exhibition (SID): May 23-27, 1988, 
Anaheim, Calif. Submit abstracts and tech¬ 
nical summaries by Dec. 7,1987, and final 
manuscripts by March 28,1988, to Lynne A. 
Henderson, Society for Information Display, 
c/o Palisades Institute for Research Services, 
Inc., 201 Varick St., Rm. 1140, New York, 
NY 10014; (212) 620-3375. 

NCC 88, National Computer Confer¬ 
ence (Computer Society, AFIPS, 

ACM, DPMA, SCS): May 31-June 3, 1988, 
Los Angeles. Papers are sought by Dec. 11, 
1987, addressed to NCC 88, ISA Services, 
Inc., PO 12277, Research Triangle Park, NC 
27709;(919)549-8411. 


Third Israel Conference on Computer 
Systems and Software Engineering 
(Israel chapter of the Computer Society; 
Information Processing Assoc, of Israel): 
June 6-7, 1988, Tel Aviv. Four copies of 
extended abstracts are sought by Dec. 1, 
1987 addressed to Amiram Yehudai, c/o 
ORTRA Ltd., PO 50432, Tel Aviv 61500, 
Israel; telephone (972) 3-664825. Final ver¬ 
sions are due by April 10, 1988. 


17th MUMPS Users’ Group Meeting: June 
13-17, 1988, New Orleans, La. Six copies of 
draft manuscripts are due by Dec. 1, 1987, 
and final manuscripts are due by March 15, 
1988 addressed to MUMPS Users’ Group, 
4321 Hartwick Rd., Suite 510, College Park, 
MD 20740; (301)779-6555. 

Third International Workshop of the 
Bellman Continuum (INRIA): June 13-14, 
1988, Sophia-Antipolis, France. Submit 
abstracts by Dec. 1, 1987, and final 
manuscripts by March 1, 1988 to Prof. A. 
Blaquiere, Universite de Paris VII, Laboratoire 
d’Automatique Theorique, Tour 14-24, 2 
Place Jussieu—75251 Paris Cedex 05, 

France. 

Symposium on the Engineering of 
Computer-Based Medical Systems: 

June 8-10, 1988, Minneapolis. Four copies of 
manuscripts are required by Dec. 2,1987, 
addressed to Bart Galle, Continuing Medical 
Education, Box 202, University of Min¬ 
nesota Medical Clinic, 420 Delaware St. SE, 
Minneapolis, MN 55455; (612) 626-5525. 

Ninth International Conference on Pattern 
Recognition (IAPR): Oct. 17-20, 1988, Bei¬ 
jing. Four copies of complete drafts, includ¬ 
ing abstracts, are sought by Dec. 2,1987, 
addressed to Herbert Freeman, CAIP Cen¬ 
ter, Busch Campus, Rutgers University, New 
Brunswick, NJ 08903; (201) 932-3443. 

SIGMOD 88, Conference on Management of 
Data (ACM), June 1-3, 1988, Chicago. 
Papers are sought by Dec. 4, 1987, in two 
tracks: (1) concepts and techniques (send to 
Per-Ake Larson, Dept, of Computer Sciences, 


Second International Conference on Vector 
and Parallel Computing (SIAM): June 6-10, 
1988, Tromso, Norway. Submit abstracts by 
Dec. 11, 1987, to Berit Hilt, Bergen Scien¬ 
tific Center, Allegaten 36, 5000 Bergen, 
Norway. 

Workshop on Parallel and Distributed 
Debugging (ACM): May 5-6, 1988, Madison, 
Wis. Submit eight copies of extended 
abstracts by Dec. 15, 1987, and final papers 
by April 1, 1988, to Bart Miller, Computer 
Sciences Dept., University of Wisconsin, 

1210 W. Dayton St., Madison, WI 53706; 
(608) 263-3378. 

Third International Conference on Data and 
Knowledge Bases: June 28-30, 1988, Jerusa¬ 
lem. Five copies of papers or extended 
abstracts are sought by Dec. 20, 1987 
addressed to C. Beeri, Databases Confer¬ 
ence, PO 29313, Tel Aviv 61292, Israel; tele¬ 
phone (972) 02-585266. 

Third International IEEE Conference on 
Ada Applications and Environments, May 
23-26, 1988: Manchester, N.H. Papers, due 
by Dec. 30, 1987, should be submitted to 
Dewayne E. Perry, AT&T Bell Laboratories, 
Rm. 3D-454, 600 Mountain Ave., Murray 
Hill, NJ 07974; (201) 582-2529. 

Eurographics 88, Ninth Conference of the 
European Assoc, for Computer Graphics 
(INRIA): Sept. 12-16, 1988, Nice, France. 
Five copies of papers are due by Dec. 31, 
1987 addressed to INRIA, Service des Rela¬ 
tions Exterieures, Domaine de Voluceau— 
BP 105, 78153 Le Chesnay Cedex, France; 
telephone (33) 1-39-63-55-01. 

15th IFAC Workshop on Real-Time Pro¬ 
gramming: May 25-27, 1988, Valencia, 

Spain. Five copies of drafts are sought by 
Jan. 1, 1988, addressed to WRTP 88, Grupo 
de Informatica Industrial—DSIC/DISCA, 
Universidad Politecnica de Valencia, PO 
22012, E-46071 Valencia, Spain; phone (34) 
6-3604041. 

26th Assoc, for Computational Linguistics 
Meeting: June 7-10, 1988, Buffalo, N.Y. 


Twelve copies of extended drafts should be 
submitted by Jan. 4, 1988 to Jerry R. Hobbs, 
Artificial Intelligence Center, SRI Interna¬ 
tional, 333 Ravenswood Ave., Menlo Park, 
CA 94025; (415) 859-2229. 


Fifth International Conference on Testing 
Computer Software (DPMA): June 13-16, 
1988, Washington, DC. Submit extended 
abstracts by Jan. 14, 1988, and papers by 
April 1, 1988 to US Professional Develop¬ 
ment Institute, 1734 Elton Rd., Suite 221, 
Silver Spring, MD 20903; (301) 445-4400. 


CAD/CAM Technology Transfer to Latin 
America Conference (IFIP): Aug. 22-26, 
1988, Mexico City. Submit five copies of 
paper (1000 to 5000 words) plus abstract on 
any area of CAD/CAM/CAE by Jan. 15, 
1988 to G. Leon Lastra, Instituto de Inves- 
tigaciones Electricas, Apdo. Postal 5-849, 
11590 Mexico, D.F. 


Eighth International Symposium on Pro¬ 
tocol Specification, Testing, and Verification 
(IFIP): June 7-10, 1988, Atlantic City, N.J. 
Submit five copies of papers by Jan. 15, 1988 
to Sudhir Aggarwal, Bell Communications 
Research, 435 South St., Morristown, NJ 
07960; (201) 829-4477; or Krishan Sabnani, 
AT&T Bell Laboratories, 600 Mountain 
Ave., Murray Hill, NJ 07974; (201) 

582-5740. 

19th Pittsburgh Conference on Modeling 
and Simulation (IEEE, ISA, SCS): May 5-6. 
1988, Pittsburgh. Summaries and abstracts 
are sought by Jan. 31, 1988, addressed to 
William G. Vogt or Marlin H. Mickle, 
Modeling and Simulation Conference, 348 
Benedum Engineering Hall, University of 
Pittsburgh, Pittsburgh, PA 15261. Final 
manuscripts will be due by May 6, 1988. 


Eurocrypt 88, Workshop on the Theory and 
Application of Cryptologic Techniques 
(IACR): May 25-27, 1988, Davos, Switzer¬ 
land. Four copies of abstracts are sought by 
Jan. 31, 1988, addressed to Ingemar 
Ingemarsson, Dept, of Electrical Engineer¬ 
ing, Linkoping University, S-581 83 Linkop- 
ing, Sweden. 


£3^ IEEE Software and IEEE Expert are 
^5? seeking papers for special November 
1988 issues on expert systems applied to soft¬ 
ware engineering. Abstracts should be sub¬ 
mitted as soon as possible, and eight copies 
of manuscripts are due by Feb. 1,1988, all 
addressed to Murat Tanik, Dept, of Com¬ 
puter Science & Engineering, Southern 
Methodist University, Dallas, TX 75275-0122; 
(214) 692-3083, ext. 2854. 


IEEE Software: Articles on all topics 
are sought for the September 1988 
issue. Contact Ted G. Lewis, editor-in-chief, 
IEEE Software, c/o Computer Science 
Dept., Oregon State University, Corvallis, 
OR 97331; (503) 754-2744; CSnet lewis@ 
oregon-state; Compmail+ t.lewis. Materials 
are due by Feb. 1, 1988. 
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BOOK REVIEWS 


Editor: Wiley McKinzie, School ot Computer Science and Technology, Rochester Institute of Technology, Rochester, NY 14623; Compmail, w.mckinzie; CSnet, wrm@rit 


Software Components with Ada: Structures, Tools, and Subsystems 


Grady Booch (Benjamin/Cum¬ 
mings Publishing Company, Inc., 
Menlo Park, Calif., 1987, 635 pp., 
$35.95) 

The philosopher’s stone of software 
engineering, for which many have 
searched long and hard, is truly reusa¬ 
ble software: code that can be used 
without any change on many different 
projects. Search no more: Software 
Components With Ada demonstrates 
how to write truly reusable software 
using the Ada programming language. 
(For those who do not know Ada, an 
appendix provides enough of an intro¬ 
duction to understand the rest of the 
book.) 

Paraphrasing the author’s preface, 
the book’s four goals are to provide a 
catalog of reusable software compo¬ 
nents, to offer examples of good pro¬ 
gramming style using Ada, to expound 
an object-oriented software develop¬ 
ment technique, and to provide a study 
of data structures and algorithms. The 
book succeeds admirably in meeting the 
first two goals. It does not do as well on 
the last two. 

The book begins with an introduction 
to reusable software components, fol¬ 
lowed by an introduction to object- 
oriented software development, its role 
in the software life cycle, and its advan¬ 
tages over functional decomposition 
methods. Unfortunately, too little space 
is allotted to this intricate topic. Most 
of the material has been condensed 


from Booch’s earlier book Software 
Engineering With Ada (Benjamin/ 
Cummings, 1987); those interested in 
object-oriented software development 
would do better to read that book. 

The bulk of the book focuses on data 
structures and algorithms. The author 
devotes one chapter to each of the tradi- 


This book demonstrates 
how to write truly 
reusable software using 
the Ada programming 
language. 


tional data structures: stacks, lists, 
strings, queues, rings, maps, sets, bags, 
trees, and graphs. Each data structure is 
described as an abstract data type; then 
the complete Ada code is given for 
several implementations of the abstract 
data type. Typically, one implementa¬ 
tion uses a dynamically linked represen¬ 
tation to provide an unbounded structure, 
and a second uses a static array repre¬ 
sentation to provide a bounded structure. 
The abstract data types are encapsulated 
as Ada generic packages that can be 
instantiated to create “a structure of 
anything ,” for example, a list of 


integers, a tree of student records (for 
fast searching), or a graph of network 
nodes (for communications network 
analysis). Examples of application pro¬ 
grams that instantiate and use each data 
structure are also given. 

The author then presents algorithms 
built on top of the bare abstract data 
types. Many of the traditional algorithms 
are covered, including list and tree 
insertion and deletion; internal and 
external sorting; array, list, tree, and 
graph searching; and pattern matching. 
Like the abstract data types, the sorting 
and searching algorithms take the form 
of Ada generic procedures that can be 
instantiated to work on any kind of 
data. The author also presents Ada 
implementations of a storage manager 
for collecting garbage, semaphores and 
monitors for synchronizing access to 
shared data structures among concur¬ 
rent tasks, and filters and pipes for 
building an application as a collection 
of tasks that have data flowing among 
them. 

Closing the book is a chapter on how 
to organize a large software system into 
a collection of subsystems, where each 
subsystem is a collection of Ada pack¬ 
ages. The final chapter covers the 
managerial, legal, and social issues in 
employing reusable software com¬ 
ponents. 

The Ada code is the book’s best fea¬ 
ture; it alone is worth the price. The 
code is of high quality: in the thousands 
of lines that I read, I found only two 
slight errors. The code is immediately 
usable. One could type it in without any 
changes and instantly start using it on a 
real software project. (Incidentally, the 
book’s copyright page states, “All of 
the software described in this book is 
available in machine-readable form 
from the author.”) The author has 
excellently demonstrated how to exploit 
Ada’s capabilities to develop truly reus¬ 
able, portable software. The author has 
also provided many practical examples 
of good Ada coding style and of how to 


For review, recently published books and new periodicals may be submitted 
to the editor at the address,given above. 

Note: Publications reviewed in this section are not available from the Com¬ 
puter Society of the IEEE; orders must be placed directly with the publishers. 
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use Ada’s more arcane features like 
packages, generics, attributes, aggregates, 
exceptions, and array slices. The imple¬ 
mentations of filters and pipes are par¬ 
ticularly noteworthy. Using these, one 
can take a software system described as 
a data flow diagram and map it directly 
into Ada code, with filters standing for 
processes and pipes standing for the 
data flows connecting them. 

Compared to well-known data struc¬ 
tures texts like Data Structures and 
Algorithms (A. Aho, J. Hopcroft, and 
J. Ullman, Addison-Wesley, 1983), 

Data Structures Using Pascal (A. 
Tenenbaum and M. Augenstein, 
Prentice-Hall, 1986), and Algorithms + 
Data Structures = Programs (N. 

Wirth, Prentice-Hall, 1976), this book 
does not provide particularly good 
explanatory material. The author’s 
explanations of how the data structures 
and algorithms work are mostly too 
brief and include too few pictures, espe¬ 
cially pictures of the algorithms in 
action. Although examples of both iter¬ 
ative and recursive algorithms are 
given, the author does not devote space 
to studying the differences and tradeoffs 
between iteration and recursion. While 
the author does introduce the “big-O” 
notation for expressing time and space 
complexity and lists formulas for each 
algorithm’s complexity, he does not 
devote much space to showing how the 
formulas were derived. Some important 
data structures and algorithms—including 
binary tree search, balanced trees, B- 
trees, and tries—are just mentioned 
briefly or are not covered at all. The 
area of storage management and garbage 
collection is covered, but not to the 
same depth as the texts mentioned above. 
Someone who has not already studied 
data structures and algorithms should 
study this book in conjunction with 
another data structures text. 

Despite these shortcomings, every 
software practitioner and student 
should get this book. Students will find 
it a valuable supplement to a data struc¬ 
tures and algorithms course, showing 
them how to craft practical, reusable 
software from the concepts they study. 
Students of Ada can also use it to find 
examples of the language’s features in 
use. Practitioners can use the book as a 
data structures and algorithms reference 
and a source for already-implemented 
Ada code upon which they can build 
their own applications. Even those 
working in a language other than Ada 
will find in this book many important 
lessons on how to build software that is 
truly reusable. 

Alan Kaminsky 

Rochester Institute of Technology 


The Art of Prolog: Advanced Programming 
Techniques 


Leon Sterling and Ehud Shapiro 
(MIT Press, Cambridge, Mass., 

1986, 437 pp„ $29.95) 

This book is not, nor does it pretend 
to be, an introduction to Prolog. Designed 
as a text for first-year graduate students 
in computer science, the intent of the 
authors is to present “advanced pro¬ 
gramming techniques that have evolved 
in the Prolog community” and to show 
how those techniques “can be combined 
to build application programs.” 

Part I, Chapters 1 through 5, is a self- 
contained introduction to logic pro¬ 
gramming. Topics include the basic 
constructs of logic programs, database 
and recursive programming styles, and 
the computational model of logic pro¬ 
gramming. Part II, Chapters 6 through 
13, contains valuable discussions of the 
pure Prolog computational model, 
system-defined predicates for enhancing 


The chapters that 
introduce and illustrate 
advanced techniques are 
worth the price of the 
book. 


the expressiveness of the model, and 
basic declarative programming tech¬ 
niques. In Part III, Chapters 14 through 
19, advanced techniques are introduced 
and illustrated. These chapters, cover¬ 
ing nondeterminism, incomplete data 
structures, definite clause grammars, 
second-order programming, and the use 
of meta-interpreters, are alone worth 
the price of the book. Larger applica¬ 
tions, built on materials developed 
earlier, are the subject of Part IV, Chap¬ 
ters 20 through 23. The authors provide 
complete code for game-playing pro¬ 
grams illustrating the minimax algo¬ 
rithm with alphabeta pruning, a 
prototype expert system for evaluating 
credit applications, a symbolic equation 
solver, and a compiler for a subset of 
an Algol-type language. Each applica¬ 
tion is extensively annotated. 

The Art of Prolog is professionally 
packaged with few typos and an excel¬ 
lent index. Background sections and 
exercises accompany each chapter. The 
authors’ style is generally adequate, 
although on occasion so compact as to 
be all but unintelligible to the general 
reader. Perhaps this is forgivable, given 


the target audience. Example programs, 
written in Wisdom Prolog, are available 
on disk from MIT Press for $15.95. A 
Wisdom interpreter may be purchased 
for $95.00. 

What I particularly like about The 
Art of Prolog is its uncompromising 
insistence on the declarative program¬ 
ming paradigm. On one level, this book 
can be viewed as a sustained and rigor¬ 
ous investigation of the relationship 
between the logic programming com¬ 
putational model and Prolog, the most 
successful implementation of that 
model to date. The assumption of the 
authors, shared by many in the Prolog 
community, is that only by understand¬ 
ing that relationship can one hope to 
exploit the full potential of Prolog. In a 
recent issue of AIExpert (June 1987), 
Fernando Pereira complained that 
“existing books tend to present Prolog 
in the manner of a stand-up comedian 
flashing one clever feature after another. ’ ’ 
The Art of Prolog is a refreshing and 
timely exception. 

Kevin Donaghy 

Rochester Institute of Technology 


Using CADKEY 

Paul J. Resetarits and Gary R. 

Bertoline (Delmar Publishers, 

Inc., Albany, N.Y., 1987, 326 pp., 
$35.95) 

CADKEY is a very popular 3D 
mechanical CAD system (over 30,000 
copies sold at $2700 each) that I have 
used and reviewed for IEEE Software 
(May 1987). Since I really like the soft¬ 
ware, I was looking forward to reading 
the book. Both authors are knowledge¬ 
able, even experts, in the field, and one 
of them (Resetarits) was instrumental in 
developing the CADKEY Users’ Refer¬ 
ence Manual. 

The preface says that this is a text¬ 
book for those learning to use the sys¬ 
tem, and can either be a classroom text 
or a supplement to the users’ reference 
manual. Included with the text are two 
work disks. 

Frankly, I was not too impressed. 

The book reads more like a reference 
guide than anything else. Since the 
guide that comes with CADKEY is 
pretty good, this book should offer 
something more than a rehash of the 
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contents of the manual. Unfortunately, 
it doesn’t. 

The book includes 17 chapters. The 
first two describe CAD, CAM, and 
CIM (computer-integrated manufactur¬ 
ing). The third explains the CADKEY- 
human interface (which makes CAD- 
KEY so nice to use). The remaining 
chapters correspond to primary and 
secondary menus in CADKEY. 

The book gives many examples, lots 
of figures, and an explanation of the 
possible uses of the CADKEY feature 
being discussed. Exercises at the end of 
each chapter include drawings found 
within the chapter and on the work 
disks. These exercises have you go 
through the steps outlined in the “Pos¬ 
sible Use of...” sections that are part of 
each chapter. 

In most cases the exercises are very 
helpful. However, a particularly bad set 
of examples appears in Chapter 13, 
“Detailing Your Design.” Here the 
authors have given examples that don’t 
work because the example drawing has 
been executed incorrectly or a typo 
invalidates the command string given. 
Also, one of the examples is meaning¬ 
less (because the rescale doesn’t make 
sense unless you know that the original 
example is not at a 1:1 scale). And 
finally, just when an example would be 
helpful (such as in the discussion on 
cross hatching), none is given. While 
the astute user will be able to work out 
all the problems, the less astute user will 
just get bogged down. 

My main complaint, however, con¬ 
cerns the presentation. As a textbook 
writer myself, I’m one who believes that 
a textbook should be conceptually 
organized rather than simply list the 
facts. The book ought to start with just 
the basics: what you need to know to 
get you going. Then, it ought to use 
these basics to enable the reader to cre¬ 
ate meaningful drawings, adding new 
features of CADKEY as required. In 
other words, the authors shouldn’t try 
to go through CADKEY using a top- 
down menu approach, but rather they 
should help the reader understand what 
tools are needed to develop a complete 
drawing. 

While the book is easy to read, it 
doesn’t appear to offer much over the 
reference manual. I didn’t find enough 
new material to justify purchasing the 
book. Certainly the recitation of facts 
doesn’t particularly assist the reader in 
becoming a (more) proficient CADKEY 
user. Consequently, I didn’t really find 
this book overly helpful and I can’t 
recommend it. 

Richard Eckhouse 
MOCO, Inc. 


Data Communications Networking Devices: 
Characteristics, Operation, Applications 

Gilbert Held (John Wiley & Sons, The appendices cover two computer 

Inc., New York, 1986, 360 pp., programs for those readers actually 

$29.95) involved in the sizing of network 


Data communications networking 
devices are the building blocks upon 
which networks are constructed. The 
stated goal of the author of Data Com¬ 
munications Networking Devices: 
Characteristics, Operation, Applica¬ 
tions is to provide the reader with an 


There has long been a 
need for a book on these 
devices. 


“intimate awareness of the numerous 
devices which can be employed in the 
design, modification or optimization of 
a data communications network.” In 
my opinion, he has achieved this goal 
admirably. 

There has long been a need for a 
book on this subject. When I took a 
course in data communications at 
NCSU in Spring 1985, the teacher had 
to teach from his own notes compiled 
from various sources. The book under 
review covers much of that course mate¬ 
rial and more. 

The book is designed to provide the 
reader with a detailed understanding of 
the operation and utilization of commu¬ 
nications devices. It covers a lot of 
ground—from transmission techniques 
to error detection and correction, from 
modems to concentrators and front-end 
processors, from redundancy and relia¬ 
bility aids to automatic assistance 
devices, and from speed and mode con¬ 
verters to inverse multiplexing with 
multiport modems. 

The writing style is excellent. The 
author strikes an intelligent balance 
between readability and scholarship. 
Specific topics are treated within a half¬ 
page or page to keep the size of the 
book within acceptable limits. There are 
numerous illustrations and schematic 
diagrams. The review questions at the 
end of each chapter are good, and an 
instrument manual is available from the 
publisher. 

I liked the depth of treatment of the 
section on cyclic or polynomial code. 
However, I felt that the section on 
“protocol converters” could have been 
longer. 


devices. After reading the appendices 
and executing the computer programs, 
the reader can reduce many sizing prob¬ 
lems to a table lookup procedure. 

This book is suitable for a one- 
semester course at a high-level under¬ 
graduate or a first-year graduate course 
level. Once again, a need has been ful¬ 
filled. 

Chanden Sen 


Knowledge Systems and 
Prolog: A Logical 
Approach to Expert 
Systems and Natural 
Language Processing 

Adrian Walker (ed.), Michael 
McCord, John F. Sowa, and 
Walter G. Wilson (Addison- 
Wesley Publishing Company, 

Inc., Reading, Mass., 1987, 475 
pp., $30.95) 

The authors of this book have set 
themselves an ambitious task. They 
attempt to cover a wide range of sub¬ 
jects, including the Prolog language, 
expert systems, and natural language 
processing, using logic as their central 
theme. In general, they do not succeed 
as well as could be hoped. 

The major flaw in the book is the 
unevenness of the coverage, which 
ranges from introductory to advanced, 
and from general to highly detailed. As 
the authors themselves note, the book 
has “an unusual span of topics and 
levels.” However, the book has a 
modular organization, and readers 
interested in only certain of the topics 
are guided to the relevant sections. 

The book begins with a fairly low- 
level introduction to knowledge systems 
and Prolog, but introduces the unifying 
theme of logic in a clear fashion. It con¬ 
tinues with an introduction to IBM Pro¬ 
log and some advanced programming 
methods. The emphasis seems more on 
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logic than on the teaching of Prolog. I 
feel few could learn Prolog from this 
discussion by itself, especially since it 
makes no attempt to discuss any other 
Prolog implementation. There are some 
exercises, but no answers are supplied 
for those not done in the text. 

By the third chapter, a most welcome 
section on style in writing Prolog pro¬ 
grams is presented and illustrated with 
several advanced examples. These are 
interesting in themselves, but may be 
beyond a person whose only knowledge 
of Prolog comes from the introduction. 


The authors attempt to 
cover a wide range of 
subjects, including the 
Prolog language, expert 
systems, and natural 
language. 


Expert systems are treated by very 
briefly considering knowledge represen¬ 
tation, looking at two shells (one of 
which uses confidence weights), and 
considering explanation and knowledge 
checking. In these areas, both concepts 
and their Prolog implementations are 
presented. 

The book concludes with a discussion 
of natural language processing in Pro¬ 
log. The authors start by introducing a 
logical form language, then they 
develop logic grammars, and finally 
they consider syntactic constructs and 
semantic interpretations. The discussion 
is detailed and interesting, and the final 
example, a natural language interface to 
a university course database, is cleverly 
chosen. 

The book also features appendices on 
IBM Prolog usage and the logical basis 
for the expert system shells. 

For an introduction to Prolog and 
expert systems, either as a course text or 
a self-tutorial, this book is not the best 
possible choice. Better introductions are 
available (for example, Ivan Bratko’s 
Prolog Programming for Artificial 
Intelligence, Addison-Wesley, 1986). 

For an advanced treatment of selected 
expert systems topics or for a sophisti¬ 
cated discussion of natural language 
processing, this book has much to 
offer. 

Walter A. Wolf 

Rochester Institute of Technology 


Image processing. A Frost & Sullivan 
report called The US Commercial Mar¬ 
ket for Image Processing Systems (# 
A1771, 319 pp., $1950) explores the 
market segments of image processing. 
The report forecasts total commercial 
market growth from $470.4 million in 
1986 to $532.3 million in 1987 and to $1 
billion by 1992. Specifically, artificial 
vision is predicted to reach 40 percent 
of the image processing market by 1992. 

The report The Analog-to-Digital and 
Digital-to-Analog Conversion Compo¬ 
nents Market in the US (Ml 781, 288 
pp., $1950) from Frost & Sullivan 
covers the products that make commu¬ 
nication possible between a computer or 
digital chip and the non-numerical sig¬ 
nals in common use. The study predicts 
that US industry will spend more than 
$1.4 billion a year by 1991 for equip¬ 
ment to translate the real world into a 
digital realm and back again. The 
report includes market segments, tech¬ 
nologies, and companies. 

Customer Service, Frost & Sullivan, 
106 Fulton St., New York, NY 10038; 
(212) 233-1080 or Frost & Sullivan, Sul¬ 
livan House, 4 Grosvenor Gardens, 
London SW1W ODH; (01) 730-3438. 

Process control. Using material from 
Hydrocarbon Processing magazine, edi¬ 
tor Les A. Kane put together the Hand¬ 
book of Advanced Process Control 
Systems (ISBN 0-87201-721-4, 368 pp., 
$55). The handbook is divided into 
three major sections: instrumentation 
applications, advanced and conven¬ 
tional control strategies, and advanced 
and conventional control aids. Gulf 
Publishing Co., Book Div., Dept. R7, 
PO Box 2608, Houston, TX 77252. Add 
$6 each for shipping and handling. 

Network for problem solving. The 

Teltech Resource Network is an infor¬ 
mation service centered on a computer¬ 
ized network that sets up person-to-person 
communications between client compa¬ 
nies and engineers and scientists from 
universities, national laboratories, and 
private industry throughout the US. 

The network offers expert consultation 
in over 1400 scientific areas. The service 
package comes with PC-compatible, 


custom-designed software. Users enter a 
topic and receive the names of scientists 
in that area who will field questions. A 
yearly charge based on client needs 
allows unlimited access. The charge 
ranges from $3000 to $10,500. The net¬ 
work also includes an interactive litera¬ 
ture search capability. Contact Ron 
Helgeson, Corporate Communications, 
Teltech Corp., 9855 W. 78th St., Min¬ 
neapolis, MN 55344; (612) 829-9000. 

MAP Product Guide introduces con¬ 
siderations in planning and implement¬ 
ing a Manufacturing Automation 
Protocol network; describes products 
and product lines; and lists block dia¬ 
grams, pricing, and references. The 
guide costs $175 ($215 outside the US) 
and is available from Architecture 
Technology Corp., PO Box 24344, 
Minneapolis, MN 55424; (612) 

935-2035. 


Video & Graphics Presentation Systems 
(200 pp., $995) considers a range of 
technologies, software, and subsystems 
that permit the manufacture of micro¬ 
computer- or workstation-based presen¬ 
tation development systems with 
capabilities for color, animation, video, 
sound, and so forth. The report concen¬ 
trates on integrated systems with a cur¬ 
rent or expected price range of up to 
$100,000. Primary analysis targets US 
business applications, but government 
and education markets are also included. 
International Planning Information, 

465 Convention Way, #\, Redwood 
City, CA 94063; (415) 364-9040. 

Productivity Resource Guide is offered 
free of charge by the Institute of Indus¬ 
trial Engineers. Its avowed purpose is to 
assist people in industry and business 
who wish to improve their productivity 
so as to better compete in the world 
trade market. The guide covers IIE 
products and services geared toward 
productivity improvement. It also pro¬ 
vides an alphabetical listing of some US 
and international productivity centers 
and related organizations. HE, 25 Tech¬ 
nology Park/Atlanta, Norcross, GA 
30092; (404) 449-0460. 
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